数据库ER建模：Painting/Sculpture是否可设为Art的弱实体子类

你提出的移除子类独立主键、直接用关联超类的外键作为子类主键的思路，是关系型数据库实现泛化（继承）关系的标准方案，比当前冗余存储PaintingID、SculptureID的设计更贴合业务语义，三个问题的具体结论如下：

1. 子类是否可设置为弱实体，ER图是否需要标注 #

完全可以。
弱实体的核心判定标准是：实体无法通过自身属性生成唯一主键，必须依赖所关联的强实体的主键唯一标识自身实例，且实体实例不能脱离关联的强实体独立存在。
移除PaintingID、SculptureID后，Painting和Sculpture的每一条记录都必须对应唯一一条Art表记录，ArtID同时承担外键、主键两个作用，完全符合弱实体的定义。
如果严格遵循ER图绘制规范，这两个子类需要标注为弱实体：用双矩形表示弱实体，二者和Art之间的关联属于识别联系（identifying relationship），用双菱形表示即可。
额外提一句：当前保留子类独立主键的设计属于冗余字段，反而可能出现同一个ArtID对应多条子类记录的逻辑错误，比如同一个艺术品被重复标记为多幅绘画，破坏继承关系的1:0/1关联约束。

2. 超类是否可以拥有弱实体类型的子类 #

完全可以，不存在任何建模逻辑冲突。
超类-子类的泛化关系本身就隐含强依赖约束：子类实例不可能脱离超类实例独立存在——不存在不属于任何艺术作品（Art）的绘画（Painting），也不存在不属于任何艺术作品的雕塑（Sculpture）。这种依赖特性和弱实体的定义天然契合，是非常自然的建模选择。
反而给子类加独立主键的设计，会弱化这种依赖约束，如果没给子类表的ArtID加非空+唯一约束，甚至可能出现没有对应Art记录的孤儿绘画/雕塑数据，不符合业务逻辑。

3. 子类存在外键引用是否仍符合弱实体定义 #

符合。
外键引用所依赖的强实体主键，本身就是弱实体的核心特征，从来不是判定弱实体的排除条件。弱实体必须通过外键关联到其所有者强实体，要么直接使用强实体主键作为自身主键（也就是你计划采用的设计，属于最典型的ID依赖型弱实体），要么将强实体主键和自身的部分区分属性组合作为联合主键。
常见的订单明细表就是典型的弱实体：它通过外键关联订单表主键，没有独立存在的意义，没人会因为它有外键就否定它的弱实体属性。

优化后的建表SQL参考 #

移除了冗余的子类独立主键，直接将ArtID设置为子类表的主键+外键，同时修正了原SQL中语义不匹配的约束名：

-- 超类表Art，本身是Asset的子类
CREATE TABLE Art(
    ArtID   VARCHAR(50) NOT NULL PRIMARY KEY,
    ArtName VARCHAR(50),
    AssetID VARCHAR(50) FOREIGN KEY REFERENCES Asset(AssetID),
    ArtistId VARCHAR(50) FOREIGN KEY REFERENCES Artist(ArtistID),
    MadeBy VARCHAR(50) FOREIGN KEY REFERENCES Artist(ArtistName),
    CONSTRAINT UC_ArtName UNIQUE (ArtName) -- 原约束名UC_Person和表语义不符，调整命名
);

-- 子类表Painting
CREATE TABLE Painting(
    ArtID VARCHAR(50) NOT NULL PRIMARY KEY FOREIGN KEY REFERENCES Art(ArtID),
    CanvasType VARCHAR(50)
);

-- 子类表Sculpture
CREATE TABLE Sculpture(
    ArtID VARCHAR(50) NOT NULL PRIMARY KEY FOREIGN KEY REFERENCES Art(ArtID),
    Material VARCHAR(50),
    Style VARCHAR(50),
    Dimension VARCHAR(50)
);

这种设计天然保证了一个Art作品最多只能对应一个Painting或Sculpture记录，从表结构层面避免了同一个艺术品同时被标记为绘画和雕塑的逻辑错误，同时减少了不必要的字段存储开销。

内容的提问来源于stack exchange，提问作者Rad Jre