如何确保循环关系表上的参照完整性

时间:2019-08-06 18:07:16

标签: mysql database database-design

我有类似this

的架构

在此数据库中,

  • 章节有很多作用
  • 章节有很多访客
  • 访客属于角色

我的问题是,如何确保the visitor and its role should have same chapter_id

有什么想法吗?

2 个答案:

答案 0 :(得分:0)

您在visitor表中不需要Chapter_id。这是多余的,因为您可以从role_id告诉访问者所属的章节。

答案 1 :(得分:0)

注释

[p x]   = predicate  x
(c x.y) = constraint x.y

PK = Primary Key
AK = Alternate Key   (Unique)
SK = Proper Superkey (Unique)
FK = Foreign Key

All attributes (columns) NOT NULL

[p 1] 角色ROLE_ID存在。

(c 1.1)角色由ROLE_ID 标识。

role {ROLE_ID}  -- p 1
  PK {ROLE_ID}  -- c 1.1

[p 2] PERSON_ID存在。

(c 2.1)人物由PERSON_ID 标识。

person {PERSON_ID} -- p 2
    PK {PERSON_ID} -- c 2.1

[p 3] CHAPTER_ID章存在。

(c 3.1)章节由CHAPTER_ID 标识。

chapter {CHAPTER_ID}  -- p 3
     PK {CHAPTER_ID}  -- c 3.1

[p 4] PERSON_ID的角色为ROLE_ID

(c 4.1)对于每个人,该人可能扮演多个角色;
 对于每个角色,该角色可能属于一个以上的人。

(c 4.2)如果一个人有角色,那么该人必须存在。

(c 4.3)如果一个人有一个角色,那么该角色必须存在

person_role {PERSON_ID, ROLE_ID}    -- p 4
         PK {PERSON_ID, ROLE_ID}    -- c 4.1

        FK1 {PERSON_ID} REFERENCES
     person {PERSON_ID}             -- c 4.2

        FK2 {ROLE_ID} REFERENCES
       role {ROLE_ID}               -- c 4.3

[p 5] CHAPTER_ID章具有角色ROLE_ID

(c 5.1)对于每一章,该章可能扮演多个角色;对于每个角色,该角色可能属于多个章节。

(c 5.2)如果某个章节有角色,则该章节必须存在。

(c 5.3)如果某章具有角色,则该角色必须存在

chapter_role {CHAPTER_ID, ROLE_ID}      -- p 5
          PK {CHAPTER_ID, ROLE_ID}      -- c 5.1

         FK1 {CHAPTER_ID} REFERENCES
     chapter {CHAPTER_ID}               -- c 5.2

         FK2 {ROLE_ID} REFERENCES
        role {ROLE_ID}                  -- c 5.3

[p 6] 具有角色PERSON_ID的人ROLE_ID访问了具有角色CHAPTER_ID的章节ROLE_ID –在某个时间点。 / p>

(c 6.1)对于每个人,该人在某个时间点可能访问了多个章节。对于每一章,在某个时间点可能已经有多个人访问了该章。

(c 6.2)如果某人访问了某个角色的章节,则该人必须具有该角色。

(c 6.3)如果某个角色访问过某个章节,则该章节必须具有该角色。

visit {PERSON_ID, CHAPTER_ID, ROLE_ID}          -- p 6
   PK {PERSON_ID, CHAPTER_ID}                   -- c 6.1

        FK1 {PERSON_ID, ROLE_ID} REFERENCES
person_role {PERSON_ID, ROLE_ID}                -- c 6.2

         FK2 {CHAPTER_ID, ROLE_ID} REFERENCES
chapter_role {CHAPTER_ID, ROLE_ID}              -- c 6.3