照课件第 23 页那张全局图，属性一个不落地抄下来。
实体转表这一步没有判断，键做主码，属性照搬。
第一句把 13 张表按被引用的反序删干净，这一页才能反复跑。
地址的属性最多，照第 21 页那张图数，一共九个。
七个实体七张表，一张也不能少，联系还一个没转。
E-R 图上写密码邮箱，第 29 页写登录邮箱，是同一个属性。
用户和订单之间，图上有联系吗？
供应、属于、包含，主码都是两端键的组合。
属于这张只有两列，因为这个联系身上一个属性都没有。
课件第 30 页管它叫分类，跟分类实体重名，图上写的是属于。
供应这张表为什么必须两列做主码？
拥有、设置、使用，主码都是 n 端那个实体的键。
n 端的键单独做主码，这三张表下一次上机就会被合并掉。
课件第 27 页说 1:n 并不产生新关系，第 30 页却先建出来了。
先建再合并，跟一步到位差在哪？
七个实体加六个联系，这就是第 31 页说的那个数。
回显末行写着 13 rows in set，7 加 6 就是这个数。
E-R 图上一个实体一件事、一个联系一件事，转出来自然没有部分依赖和传递依赖。
两个商品、两个分类、一个供应商、一个用户、一个订单。
插入顺序得跟着外码走，先实体后联系，反过来就撞 1452。
先插包含再插订单会发生什么？
图上用户和订单没有直连，得顺着地址绕一圈。
八张表连起来才答得上，因为用户是靠地址挂上订单的。
订单里没有用户编号，换个收件人订单就换了主人，这是个隐患。
订单直接加一个用户编号，好不好？
头一句先删干净，从零把整张全局图落到表上。
一张 E-R 图落到十三条 CREATE TABLE，逻辑结构设计就算走完了。
这十三张表下一步该做什么？