当我第一次开始开发APEX应用程序时，我正在处理的数据库是一个结构如下的表：

|Row Header|Criteria 1|Criteria 2| Criteria 3 | Criteria 4 |Criteria 5 |
| Category | Type A   | Type B   | Type B     | Type A     | Type A    |
| ID       | 2.3      | 2.4      | 2.5        | 3.1        | 3.2       |
| Part A   | Yes      | Yes      | Yes        | No         | Yes       |
| Part B   | Yes      | No       | Yes        | Yes        | Yes       |
| Part C   | No       | Yes      | Yes        | Yes        | No        |

当时我对Oracle和数据库还很陌生，所以我根据电子表格对它建模。目的是跟踪部件是否满足必要的条件。一旦部件确实满足条件，则在部件和条件之间的交叉单元格中输入“是”。一些附加信息存储在表中，如条件ID和类别。
在做了一些研究之后，我意识到最好将它们分成三个表，结构如下：

标准表：

| Criteria   | Category | ID   |
| Criteria 1 | Type A   | 2.3  |
| Criteria 2 | Type A   | 2.4  |
| Criteria 3 | Type B   | 2.5  |

此表存储有关标准的所有附加信息。

零件表：

| Part   | Part ID |
| Part 1 | blah    |
| Part 2 | blah    |
| Part 3 | blah    |

与条件表相同，但适用于部件。

桥接表：

| Criteria   | Part   |
| Criteria 1 | Part 1 |
| Criteria 2 | Part 2 |
| Criteria 3 | Part 3 |

此表包含所有“是”回答。如果标准和部件共享一行，则表示相关部件符合相关标准。桥接表中不存在的任何部件和标准组合都不符合标准。
我将对此进行详细介绍，因为我正在使用的应用程序的用户需要oracle APEX中的“网格视图”，该视图在y轴上显示条件，在x轴上显示表格的各个部分。用户还希望能够以编辑电子表格中数据的相同方式编辑此“网格视图”中的数据，但如果这不是“It“这不是个好主意，没有它我也能活，只要你能用我概述的方式来看待它。

请求的网格视图：

| Row Header | Part 1 | Part 2 | Part 3 | Part 4 | Part 5 |
| Criteria 1 | No     | No     | Yes    | Yes    | No     |
| Criteria 3 | Yes    | No     | No     | Yes    | No     |
| Criteria 4 | Yes    | Yes    | Yes    | No     | Yes    |
| Criteria 5 | Yes    | No     | Yes    | Yes    | Yes    |
| Criteria 6 | No     | Yes    | Yes    | Yes    | No     |

根据我目前的数据结构，我遇到了很多麻烦，完成这一点，我真的很想保持这种结构，如果可能的话，因为许多其他方面的应用程序依赖于它。
需要注意的其他几件事是，部件的创建有些频繁，我在表格中使用的部件和标准的名称是占位符。这一事实使我偏离了创建一个表格，其中表格的列对应于一个部件，因为这将意味着添加和修改列相当频繁。
任何帮助都将非常感谢，我将监测这篇文章，我可以回答任何人可能有任何问题。