将局部E-R模型合并为全局E-R模型，首先要识别各局部E-R模型中的公共实体，然后从公共实体开始进行两两合并，直到所有有关联的局部E-R模型合并为一个整体，最后加入独立的局部E-R模型后得到全局E-R模型。
对于较大的数据库系统，局部E-R模型很多，而且现实世界的同一个对象在不同的局部E-R模型中可能被给予了不同的抽象，将局部E-R模型合并为全局E-R模型时难免会出现冲突。检查并消除冲突是设计全局E-R模型的重要工作内容。常见的冲突有三种，分别是结构冲突、命名冲突和属性冲突。
（1）结构冲突。
结构冲突是指同一对象在不同应用中具有不同的抽象。
第一类结构冲突是同一对象在不同的局部应用中分别被抽象为实体和属性。调整的原则是能用属性表示的对象就不要用实体表示，但是当对象的属性难以用简单属性表示时，就要在整个系统范围内把该对象用实体表示。例如，校园卡在一个局部应用中作为属性，在另一个局部应用中可以是有多个属性的实体，则我们在合并局部E-R模型时应该把校园卡作为实体。
第二类结构冲突是同一对象在不同的局部E-R模型中都被抽象为实体，但是实体的属性并不完全相同或属性的排列次序并不完全相同。因为数据库要满足所有用户的数据处理需求，因此实体的属性应该取各局部E-R模型中该实体属性的并集，再按照由主到次的顺序调整属性的顺序。例如，校园卡在一个局部应用中有卡号、开卡日期、注销日期、密码、状态等属性，在另一个局部应用中有卡号、密码、余额等属性，两个局部E-R模型合并后，校园卡实体的属性是二者的并集：卡号、密码、余额、开卡日期、注销日期、状态。
第三类结构冲突是在不同的局部应用中，实体之间的联系类型不同。例如，在一个局部应用中校园卡与商户之间是二元联系，而在另一个局部应用中校园卡、商户、商品之间是三元联系。是二元联系合适，还是三元联系合适，没有一定之规，要根据应用语义具体分析，然后对实体之间的联系类型进行设计。调整的原则是能用二元联系表示就不要用三元联系表示。例如，校园卡、商户、商品之间的三元联系，可以调整为校园卡与商户之间的二元联系和商户与商品之间的二元联系。但是并非所有的三元联系都可以用多个二元联系来表示。
（2）命名冲突。
实体名、属性名、联系名都有可能冲突，其中以属性的命名冲突尤为常见。命名冲突分为同名异义和同义异名两种情况。
同名异义是指不同意义的对象在不同的局部应用中具有相同的名字，例如，在不用的局部应用中都将实体命名为“项目”，一个是指教师承担的科研课题，一个是指学生参加的大学生创新创业项目。二者的性质、研究内容、考核指标都是不一样的，是两种不同的实体，应该用不同的实体名加以区分。
同义异名是指同一对象在不同的局部应用中被定义了不同的名字。例如，同样是学生实体，在一个局部应用中被命名为“学生”，而在另一个局部应用中又被命名为“学员”，因此，在合并为全局E-R模型时需要统一。
（3）属性冲突。
属性冲突是指同一个属性的属性域冲突，或者属性取值单位冲突。
属性域包括属性的数据类型和取值范围。属性域冲突有可能是同一属性在不同的局部应用中被定义了不同的数据类型，或者同一属性在不同的局部应用中数据类型相同但是数据的取值范围不同。例如，校园卡的卡号在一个局部应用中被定义为整数类型，而在另一个局部应用中被定义为字符类型。又如，学号在两个局部应用中都被定义为字符类型，但是在一个局部应用中学号的长度为12，在另一个局部应用中学号的长度为10。
属性取值单位冲突也很常见。例如，商品的规格属性在一个局部应用中以箱为单位，在另一个局部应用中以瓶为单位。
