er图转换为关系模式例题

ER图（Entity-Relationship Diagram）是一种用于描述实体集、属性和关系的图形化方法，常用于数据库设计。而关系模式更像是建立在ER图之上的一个逻辑数据模型，是用来表示数据之间联系的表格。将ER图转换为关系模式是数据库设计的必要过程，这里将以一个例题为基础，从多个角度进行分析讨论。

假设有这样一个ER图，描述的是一个影院的在线电影订票系统：


这个ER图包括了四个实体集：用户（User）、电影（Movie）、影院（Cinema）、场次（Show）和一个关系集：订票（Book）。下面将会分别从实体集、关系集和范式三个方面来讨论如何将它们转换为关系模式。

1. 实体集转换为关系模式

实体集可以直接转换为关系模式，每个实体集对应着一个关系（表），每个实体的属性对应着关系的字段。例如，用户集的所有属性可以转换为以下关系模式：

User(UserID, Name, Password, Gender, Phone, Email)

其中UserID为主键。

同样地，电影和影院集的关系模式如下：

Movie(MovieID, MovieName, Director, Producer, Screenwriter, ReleaseDate, Runtime, Language, Cover, Description)

Cinema(CinemaID, Name, City, Address, Phone)

Show(ShowID, MovieID, CinemaID, StartTime, EndTime, Price, Room)

其中MovieID和CinemaID作为外键，用来与订票集建立联系。

2. 关系集转换为关系模式

在ER图中，关系集用菱形表示，代表了实体集之间的关系。关系集中的属性可以转化为一个新的关系（表），其中包括关系的外键以及属性字段。例如，将订票集转换为关系模式：

Book(UserID, ShowID, Num, Price, Date)

其中UserID和ShowID作为外键，用来与用户、场次集建立联系。Num表示订票数量，Price表示总价，Date表示订单日期。

3. 范式转换

除了将ER图中的实体集和关系集转换为关系模型，还需要注意范式的问题。范式是关系模型设计中的一项重要概念，用于保证数据的一致性和完整性，避免数据冗余。常见的范式有1NF、2NF、3NF。

第一范式（1NF）：关系模式中每个属性都不可再分。

第二范式（2NF）：在满足1NF的前提下，非主键属性需要完全依赖于主键。

第三范式（3NF）：在满足2NF的前提下，非主键属性之间不存在传递依赖。

回到我们的例子，不难发现每个实体集的关系模式都满足1NF。但是电影和场次集的关系模式并不满足2NF，原因是电影和场次集的非主键属性（如电影名称、导演等信息）不完全依赖于主键（MovieID和CinemaID），而是依赖于主键的组合。因此，我们需要将每个非主键属性拆分成单独的实体集，以满足2NF。

经过拆分，最终的关系模式如下：

Movie(MovieID, MovieName, Director, Producer, Screenwriter)

Cinema(CinemaID, Name, City, Address, Phone)

Show(ShowID, MovieID, CinemaID, StartTime, EndTime, Price, Room)

其中MovieID和CinemaID作为外键，用来与订票集建立联系。

同时，还需要注意约束条件的设定，以保证数据完整性和一致性。例如，可以在Show表中设置外键约束，使其只能关联已有的电影和影院：ALTER TABLE Show ADD CONSTRAINT FK_Movie FOREIGN KEY (MovieID) REFERENCES Movie(MovieID) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE Show ADD CONSTRAINT FK_Cinema FOREIGN KEY (CinemaID) REFERENCES Cinema(CinemaID) ON DELETE CASCADE ON UPDATE CASCADE;