数据库：实验四数据库设计

一、需求分析

有用户和商家两种分类，商家可以管理商品，用户可以查看商品与购物。

用户可以加入购物车，与购买商。

用户购买时会填写不同的地址。

现在有用户表、商家表、商品表、购物车表、订单表、地址表。

看似已经可以了，其实还会有问题

假设没有购物车详情表，那么购物车表单关系模式是（购物车ID、用户ID、商品ID、数量）

主属性为购物车ID与商品ID

然而用户ID依赖于购物车ID，非主属性部分依赖一个候选码，不满足第二范式的要求

所以需要细分出一个购物车详情表

同理订单表也是，所以可以细分出购物车详情表与订单详情表。

观看大部分的购物网站可以看到可以选择分类，所以可以细分出商品类别来，这不仅仅可以实现商品的分类，而且可以加快查询商品的速度。经过以上分析可以得出以下：

表中也不纯在传递依赖，所以满足第三范式

每一个表中的决定因素均是码，所以满足BC范式。

用户表 (users) 存储用户的基本信息，包括用户ID、用户名、密码、邮箱和电话号码。管理员表 (admins) 存储管理员的基本信息，包括管理员ID、用户名、密码、邮箱和电话号码。这两个表分别用于管理普通用户和管理员的登录和权限控制。

商品表 (products) 存储商品的详细信息，包括商品ID、商品名称、描述、价格、库存量、商家ID以及所属类别ID。商品类别表 (categories) 则存储商品类别的相关信息，包括类别ID、类别名称和描述。这两个表通过 products 表中的 category_id 建立联系，一个类别下可以有多个商品。

订单表 (orders) 存储订单的基本信息，包括订单ID、用户ID、订单日期、订单状态和总金额。订单详情表 (order_items) 则记录每个订单中具体的商品信息，包括订单详情ID、订单ID、商品ID、数量和单价。 orders 表与 users 表通过 user_id 关联，一个用户可以有多个订单；同时， orders 表与 order_items 表通过 order_id 关联，一个订单可以有多个订单详情项。

用户购物车表 (cart) 存储用户的购物车信息，包括购物车ID和用户ID。购物车详情表 (cart_items) 则记录购物车中的具体商品信息，包括购物车详情ID、购物车ID、商品ID和数量。 cart 表与 users 表通过 user_id 关联，一个用户对应一个购物车；同时， cart 表与 cart_items 表通过 cart_id 关联，一个购物车可以包含多个购物车详情项。

地址表 (addresses) 存储用户的地址信息，包括地址ID、用户ID、收件人姓名、收件人电话、地址和是否为默认地址。 addresses 表与 users 表通过 user_id 关联，一个用户可以有多个地址。

表之间的关系

用户表 (users) 与 地址表 (addresses)：一对多关系。一个用户可以设置多个地址。

用户表 (users) 与 订单表 (orders)：一对多关系。一个用户可以购买，产生多个订单。

订单表 (orders) 与 订单详情表 (order_items)：一对多关系。一个订单可以包含多个订单详情项。

商品表 (products) 与 订单详情表 (order_items)：一对多关系。一个商品可以涉及在多个订单详情项中。

商品类别表 (categories) 与 商品表 (products)：一对多关系。一个类别下可以包含多个商品。

商家表 (merchants) 与 商品表 (products)：一对多关系。一个商家可以管理多个商品。

用户表 (users) 与 用户购物车表 (cart)：一对一关系。一个用户拥有一个购物车。

用户购物车表 (cart) 与 购物车详情表 (cart_items)：一对多关系。一个购物车可以包含多个购物车详情项。

商品表 (products) 与 购物车详情表 (cart_items)：一对多关系。一个商品可以出现在多个购物车详情项中。

二、E-R模型

三、关系模型

用户（用户ID，用户名，密码，邮箱，电话号码）

商家表（商家ID，用户名，密码，邮箱，电话号码）

商品（商品ID，商品名称，商品描述，价格，库存量，类别ID，商家ID）

商品类别（类别ID，类别名称，类别描述）

订单（订单ID，用户ID，订单日期，订单状态，总金额）

订单详情（订单详情ID，订单ID，商品ID，数量，单价）

用户购物车（购物车ID，用户ID）

购物车详情（购物车详情ID，购物车ID，商品ID，数量）

地址（地址ID，用户ID，收件人姓名，收件人电话，地址，是否为默认地址）

四、数据库相关数据说明与设计

五、sql

CREATE TABLE users (
    user_id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) NOT NULL,
    password VARCHAR(50) NOT NULL,
    email VARCHAR(100) NOT NULL,
    phone_number VARCHAR(15) NOT NULL
);

CREATE TABLE merchants (
    merchant_id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) NOT NULL,
    password VARCHAR(50) NOT NULL,
    email VARCHAR(100) NOT NULL,
    phone_number VARCHAR(15) NOT NULL
);

CREATE TABLE products (
    product_id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(100) NOT NULL,
    description VARCHAR(255),
    price DECIMAL(10, 2) NOT NULL,
    stock INT NOT NULL,
    category_id INT,
    merchant_id INT,
    FOREIGN KEY (category_id) REFERENCES categories(category_id),
    FOREIGN KEY (merchant_id) REFERENCES merchants(merchant_id)
);

CREATE TABLE categories (
    category_id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) NOT NULL,
    description VARCHAR(255)
);

CREATE TABLE orders (
    order_id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT,
    order_date DATETIME NOT NULL,
    status VARCHAR(20) NOT NULL,
    total_amount DECIMAL(10, 2) NOT NULL,
    FOREIGN KEY (user_id) REFERENCES users(user_id)
);

CREATE TABLE order_items (
    order_item_id INT PRIMARY KEY AUTO_INCREMENT,
    order_id INT,
    product_id INT,
    quantity INT NOT NULL,
    price DECIMAL(10, 2) NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(order_id),
    FOREIGN KEY (product_id) REFERENCES products(product_id)
);

CREATE TABLE cart (
    cart_id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT ,
    FOREIGN KEY (user_id) REFERENCES users(user_id)
);

CREATE TABLE cart_items (
    cart_item_id INT PRIMARY KEY AUTO_INCREMENT,
    cart_id INT,
    product_id INT,
    quantity INT NOT NULL,
    FOREIGN KEY (cart_id) REFERENCES cart(cart_id),
    FOREIGN KEY (product_id) REFERENCES products(product_id)
);

CREATE TABLE addresses (
    address_id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT,
    recipient_name VARCHAR(100) NOT NULL,
    recipient_phone VARCHAR(15) NOT NULL,
    address VARCHAR(255) NOT NULL,
    is_default BOOLEAN NOT NULL,
    FOREIGN KEY (user_id) REFERENCES users(user_id)
);

六、实验总结 

在此次实验中，我们对设计一个电子商务系统的数据库进行了详细的分析和设计。首先，我们定义了各种所需的表，包括用户表、商家表、商品表、订单表、订单详情表、购物车表、购物车详情表和地址表。我们重点讨论了商品类别的管理，初步设计时将类别信息单独放入商品类别表，并在商品表中通过外键引用。这样的设计具有高度的规范化，减少了数据冗余，增强了数据一致性和扩展性。

在进一步讨论中，我们探讨了将类别信息直接合并到商品表中的可能性和影响。通过分析，我们发现虽然这种设计可以简化数据库结构，但也带来了数据冗余和一致性问题，特别是在类别信息变更时需要更新多个商品记录。这样的设计虽然满足了第一范式和第二范式，但在某些情况下可能无法满足第三范式，特别是当有额外的类别相关信息时。

为了满足第三范式，并在不需要类别描述字段的情况下，我们重新设计了商品表，直接包含了类别名称。这样的设计满足了各个范式的要求，消除了非主键字段之间的依赖，确保所有非主键字段直接依赖于主键。尽管如此，这种设计仍存在数据冗余和一致性问题，特别是在处理类别信息的变更时。

通过此次实验，我们认识到在数据库设计中，规范化和实际应用需求之间的平衡至关重要。虽然高度规范化的设计有助于减少数据冗余并提高一致性，但在某些情况下，简单直观的设计可能更符合实际应用需求。然而，无论选择哪种设计，确保数据的完整性和一致性始终是数据库设计的核心目标。最终，合理的数据库设计应根据具体的应用场景和需求进行调整，以实现最佳的性能和可维护性。

心得

当我将上面的E-R图交给老师时，我本以为我设计的表之间的复杂度已经可以了，什么完整性也考虑了，可是老师当时就说了一句太“复杂”了，我当时也是迷迷糊糊的，难道写复杂了也不行吗，我百思不得其解，可是当我在完成Java实训时当时就需要这个数据库，我本以为可以就完全照搬这个，可是当我实际上手时，我就懂了老师说的“复杂了”，以下是我又重新写的数据库，当然有一些功能并不是因为复杂而去掉的，完全就是因为我懒，不想写。