回答編集履歴
9
コメント修正
test
CHANGED
|
@@ -332,7 +332,7 @@
|
|
|
332
332
|
|
|
333
333
|
"機械マスタ" m
|
|
334
334
|
|
|
335
|
-
/* パラメタ未登録の機械
|
|
335
|
+
/* 以下テーブル群はパラメタ未登録の機械も表示要なら結合方法は「LEFT JOIN」へ */
|
|
336
336
|
|
|
337
337
|
INNER JOIN "機械別パラメータ" p
|
|
338
338
|
|
8
モデル・ビュー定義の修正
test
CHANGED
|
@@ -156,9 +156,9 @@
|
|
|
156
156
|
|
|
157
157
|
以下は概念データモデル設計のほんの一例を記載します。
|
|
158
158
|
|
|
159
|
-
`機械マスタ（ID, 機械名, ... , 登録日, 変更日`
|
|
159
|
+
`機械マスタ（ID, 機械名, ... , 登録日, 変更日)`
|
|
160
|
-
|
|
160
|
+
|
|
161
|
-
`機械別パラメータ（ID, 機械ID, 連番, パラメタ名, データ区分）`
|
|
161
|
+
`機械別パラメータ（ID, 機械ID, 連番, パラメタ名, データ区分, 修正日）`
|
|
162
162
|
|
|
163
163
|
` 機械別文字列パラメータ (ID, パラメタ値)`
|
|
164
164
|
|
|
@@ -332,6 +332,8 @@
|
|
|
332
332
|
|
|
333
333
|
"機械マスタ" m
|
|
334
334
|
|
|
335
|
+
/* パラメタ未登録の機械があれば結合方法は「LEFT JOIN」へ */
|
|
336
|
+
|
|
335
337
|
INNER JOIN "機械別パラメータ" p
|
|
336
338
|
|
|
337
339
|
ON m."ID" = p."機械ID"
|
7
更に補足事項
test
CHANGED
|
@@ -222,6 +222,16 @@
|
|
|
222
222
|
|
|
223
223
|
|
|
224
224
|
|
|
225
|
+
あとグラフ化なども行うとのことで、
|
|
226
|
+
|
|
227
|
+
要件次第ですが例えば全機械の電圧のみをグラフ表示するとかがあるなら、
|
|
228
|
+
|
|
229
|
+
数値パラメタテーブルに更に種別などをもたせて・・・、
|
|
230
|
+
|
|
231
|
+
など集計の切り口は詳細テーブル内でも与えられるのかなとは思われます。
|
|
232
|
+
|
|
233
|
+
|
|
234
|
+
|
|
225
235
|
尚、**主キーはIDとなり親テーブルの機械別パラメータのIDと同一値**が入る想定です。
|
|
226
236
|
|
|
227
237
|
データ整合性の観点から各種パラメータ詳細テーブル全てのIDには、
|
6
追記
test
CHANGED
|
@@ -351,3 +351,15 @@
|
|
|
351
351
|
また、上記だと結局パラメタ値は全て文字となってしまうので、
|
|
352
352
|
|
|
353
353
|
数値パラメタのみだけに特化したビューなどを検討するのもありかもしれません。
|
|
354
|
+
|
|
355
|
+
|
|
356
|
+
|
|
357
|
+
#追記
|
|
358
|
+
|
|
359
|
+
ただし今回のケースだと上記のようなRDBのルールに厳密に則って、
|
|
360
|
+
|
|
361
|
+
手間をかけて設計するメリットが薄い気がするので、
|
|
362
|
+
|
|
363
|
+
「**EAV**」の設計パターンの対策として上記のような手法がある、
|
|
364
|
+
|
|
365
|
+
程度に抑えておくだけで良いかと思います。
|
5
蛇足部に追記
test
CHANGED
|
@@ -345,3 +345,9 @@
|
|
|
345
345
|
AND p."データ区分" = '3'
|
|
346
346
|
|
|
347
347
|
```
|
|
348
|
+
|
|
349
|
+
|
|
350
|
+
|
|
351
|
+
また、上記だと結局パラメタ値は全て文字となってしまうので、
|
|
352
|
+
|
|
353
|
+
数値パラメタのみだけに特化したビューなどを検討するのもありかもしれません。
|
4
表現修正
test
CHANGED
|
@@ -36,9 +36,9 @@
|
|
|
36
36
|
|
|
37
37
|
|
|
38
38
|
|
|
39
|
-
0. 機械情報(機械A)の登録数は今後も増加していく
|
|
39
|
+
0. 機械情報(機械A、機械Bなど)の登録数は今後も増加していく
|
|
40
|
-
|
|
40
|
+
|
|
41
|
-
0. 機械情報に付随するパラメタ値は増減恐れが高い
|
|
41
|
+
0. 機械情報に付随するパラメタ値は増減する恐れが高い
|
|
42
42
|
|
|
43
43
|
0. 機械情報に付随するパラメタのデータ型も今後増減する恐れがある（論理値、実数、文字以外が加わるなど）
|
|
44
44
|
|
3
誤字・表現修正
test
CHANGED
|
@@ -14,9 +14,9 @@
|
|
|
14
14
|
|
|
15
15
|
DB設計などについては「**SQLアンチパターン**」という書籍にて、
|
|
16
16
|
|
|
17
|
-
そのアンチパターンに陥りやすい背景、
|
|
17
|
+
その**アンチパターンに陥りやすい背景**、
|
|
18
|
-
|
|
18
|
+
|
|
19
|
-
及び
|
|
19
|
+
及び**どのように改善すべきか**までまとめられているため、
|
|
20
20
|
|
|
21
21
|
当方としては是非ご一読してほしい書籍の一つです。
|
|
22
22
|
|
2
レイアウト修正２
test
CHANGED
|
@@ -12,7 +12,7 @@
|
|
|
12
12
|
|
|
13
13
|
|
|
14
14
|
|
|
15
|
-
DB設計などについては「SQLアンチパターン」という書籍にて、
|
|
15
|
+
DB設計などについては「**SQLアンチパターン**」という書籍にて、
|
|
16
16
|
|
|
17
17
|
そのアンチパターンに陥りやすい背景、
|
|
18
18
|
|
1
レイアウト修正
test
CHANGED
|
@@ -122,9 +122,7 @@
|
|
|
122
122
|
|
|
123
123
|
#EAVを用いない設計方針として
|
|
124
124
|
|
|
125
|
-
「**EAV**」を回避し、
|
|
126
|
-
|
|
127
|
-
RDBらしく課題解決に拘るのであれば、
|
|
125
|
+
「**EAV**」を回避しRDBらしく課題解決に無理に拘るのであれば、
|
|
128
126
|
|
|
129
127
|
一例としてあげるなら以下のようなデータモデリングとなる気がします。
|
|
130
128
|
|
|
@@ -178,7 +176,7 @@
|
|
|
178
176
|
|
|
179
177
|
今後、**機械一覧検索などが必要になった際に一覧表示する情報はここで管理**するとよいでしょう。
|
|
180
178
|
|
|
181
|
-
尚、主キーはIDの想定です。
|
|
179
|
+
尚、**主キーはID**の想定です。
|
|
182
180
|
|
|
183
181
|
|
|
184
182
|
|
|
@@ -190,7 +188,7 @@
|
|
|
190
188
|
|
|
191
189
|
こちらでは**機械別パラメータの一覧だけを管理**します。
|
|
192
190
|
|
|
193
|
-
尚、主キーはIDで、機械ID、連番に対して複合一意キーを付与する想定です。
|
|
191
|
+
尚、**主キーはIDで、機械ID、連番に対して複合一意キーを付与**する想定です。
|
|
194
192
|
|
|
195
193
|
|
|
196
194
|
|
|
@@ -224,7 +222,7 @@
|
|
|
224
222
|
|
|
225
223
|
|
|
226
224
|
|
|
227
|
-
尚、主キーはIDとなり親テーブルの機械別パラメータのIDと同一値が入る想定です。
|
|
225
|
+
尚、**主キーはIDとなり親テーブルの機械別パラメータのIDと同一値**が入る想定です。
|
|
228
226
|
|
|
229
227
|
データ整合性の観点から各種パラメータ詳細テーブル全てのIDには、
|
|
230
228
|
|