我建议设计一个代表游戏事件和动作窗口序列的设计,它们通过属于同一序列步骤来相互关联。
也就是说,引入“游戏序列”和“游戏序列详细信息”实体,通过在“游戏序列”中具有相同的序列步骤来表示“游戏事件”和“动作窗口”的共享排序事实(避免使用连接表的设计),因为考虑到“游戏事件与动作窗口无关”。
SCHEMA
+--------------+ 1 1,n +-------------------+ 1,n
| game_phase +------------+ game_phase_play +----+
| | | | |
+--------------+ +-------------------+ |
|
| 1
+--------------------------+ 1,n 1 +---------+---------+
| gaming_sequence_detail +---------------+ gaming_sequence |
| | | |
++--------+----------------+ +-----+-------------+
| 1,n | |
| +---+ seq_step +---+ seq_steps_number
|
|
| +--------------+
| +-----+ game_event |
| 1,n +----------------+ | | |
+-----+ gaming_value | <-------+ +--------------+
| | | +-----------------+
+----------------+ +-----+ action_window |
| |
+-----------------+
前缀
gph_ === game_phase_
gseq_ === gaming_sequence_
gv_ === gaming_value_
表格
game_phase ( id , description, ... )
game_phase_play ( id , gph_id, gseq_id, date, description, ... )
gaming_sequence ( id, seq_steps_number, ... )
gaming_value ( id , type, ... )
gaming_sequence_detail ( gseq_id, gv_id, seq_step, ... )
我还为“游戏事件”和“动作窗口”引入了一个通用实体,名为“游戏值”,适用于被包含在“游戏序列”中。这种概括可以表示一种游戏不可变值(在我们的情况下有2种不同类型,但可扩展),因此选择了这个命名(从“游戏物化”和“游戏可观察”之间切换)。
两种类型的“游戏值”在“游戏序列”中通过
gaming_sequence_detail
中
(gseq_id, seq_step)
对的相等性“步进在一起”。(有人可能会认为这种“配对”是一种关系;这种解决方案更像是在表示序列步骤中的兄弟姐妹,还允许扩展到超过2种类型的“游戏值”)。
“游戏序列详细信息”中的“游戏事件”和“动作窗口”可以独立修改,也可以出现“未配对”的情况。
gaming_sequence_detail
中的约束是对于每个
seq_step
值,都可以存在一个
game_event
和一个
action_window
,因此单个
gseq_id
的
seq_step
的最大基数为2。
如果是这种情况,同一
gaming_value
也可以在同一序列中出现多次。此外,这种设计还可以表示不同“游戏阶段玩法”之间共享的序列。