前言

本文旨在通过项目示例将ER建模应用于SQL数据库，这是一个明智的尝试。尽管我尝试包括每个技术术语的链接，但这并不是ER建模的全面初学者指南。但是，我确实计划发布ER建模指南，因此，如果我的解释有助于您更好地理解ER模型，请通过评论或DM让我知道。

什么是HypeTracker？

HypeTracker是一个数据聚合器应用程序，它从社交媒体平台（如Reddit和Twitter）中获取数据，以显示一段时间内人们提到运动鞋的次数。该数据是有价值的，因为售后运动鞋的价格在特定时间点可能受到所述运动鞋的关注或“炒作”的影响。通过收集这些数据并以图形形式显示它，用户可以根据感知价值通过社交媒体关注做出是否购买某款运动鞋的明智决策，并将其与商品价格历史进行比较。

使用ER建模设计数据库

该项目主要以数据为中心，因此我们希望设计存储和访问数据的方法，以免出现诸如数据关系不正确或条目重复的问题。所描述的错误可能迫使我们删除数据库并从头开始，这可能会令人沮丧，具体取决于项目的进度。

实体和属性

在HypeTracker中，我们使用实体关系（ER）建模作为在SQL中实现数据模型之前直观地描述我们的数据模型的方式。我们首先列出了最重要的实体（现实世界的对象）：

运动鞋-此应用程序的主题重点
成员-我们应用程序的用户
排名-存储运动鞋提及/出现的历史数据

接下来，我们写下每个实体要考虑的一些属性（特征或信息）。

球鞋	会员	排名
名称	名称	平台
牌	电子邮件	提及
价钱*	密码	日期

***发行时的零售价（不是价格历史记录）

请记住，这只是我们想到的初始项目集，后来添加了更多属性。但是，此图表为我们提供了应用程序所需的最重要属性的基线，并为我们提供了简化的视图，供我们在数据模型变得复杂时参考。

实体之间的关系

在下一阶段，我们开始通过简单的实体交互方式来定义实体之间的关系。

运动鞋和会员

每个运动鞋可由一个或多个成员监视
每个成员可以监视一个或多个运动鞋

运动鞋和排名

每个运动鞋的排名都可以为零或更多
每个排名只能包含一个运动鞋

***成员和排名实体之间没有关系

实体关系可以通过其基数建模，这可以为其关系添加数字表示。例如，运动鞋和成员具有多对多的关系，因为一个运动鞋可以被许多成员观看，而一个成员可以观看许多运动鞋。同时，运动鞋和排名之间存在一对多的关系，因为一个运动鞋可以具有零个或多个关联的等级，但是每个排名只能描述一个运动鞋。

使用Crow的脚基数表示法将所有这些转换为符号，这就是我们的ER图此时的样子。

弱实体集

在这一点上要确定的关键点是，如果没有至少一个Sneaker实体，就不会存在排名实体。这会创建另一种类型的关系，其中弱实体（排名）对强实体（存在者）存在依赖关系。我们可以通过将关系更改为双菱形，将弱实体更改为双矩形，并在弱实体和弱关系之间使用两条线来表示。

多对多关系

不幸的是，我们还没有完成这个数据模型。另一个明显的问题是运动鞋和会员实体之间的基数。多对多关系在SQL中造成问题，例如数据库中的一个成员行如何同时存储许多运动鞋？此外，还有其他问题和建议的解决方案，您可以在本文中阅读，但建议的解决方案是使用关联实体。

使用关联实体，我们可以将运动鞋和成员之间的关系重构为新的监视列表实体，该实体可以跟踪成员及其运动鞋。

整理起来

现在我们基本完成了！只需添加外键作为属性并在主键下划线，这就是生成的ER图：

这是在MariaDB（v10.1.35）中实现此目标的SQL文件：

/* hypetracker.sql */

CREATE DATABASE IF NOT EXISTS HypeTracker;

USE HypeTracker;

CREATE TABLE IF NOT EXISTS `Sneakers` (
  `Name` VARCHAR(100) NOT NULL,
  `Price` DECIMAL(9,2) UNSIGNED,
  `Brand` VARCHAR(40) NOT NULL,
  CONSTRAINT `PK_Sneakers` PRIMARY KEY (Name)
) ENGINE=InnoDB;

CREATE TABLE IF NOT EXISTS `Members` (
  `Name` VARCHAR(40) NOT NULL,
  `Email` VARCHAR(100) NOT NULL,
  `Password` VARCHAR(40) NOT NULL,
  CONSTRAINT `PK_Members` PRIMARY KEY (Email)
) ENGINE=InnoDB;

CREATE TABLE IF NOT EXISTS `Watchlist` (
  `SneakerName` VARCHAR(100) NOT NULL,
  `MemberEmail` VARCHAR(100) NOT NULL,
  CONSTRAINT `PK_Watchlist` 
    PRIMARY KEY (SneakerName, MemberEmail),
  CONSTRAINT `FK_Watchlist_Sneakers`
    FOREIGN KEY (SneakerName) 
    REFERENCES Sneakers(Name)
    ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `FK_Watchlist_Members`
    FOREIGN KEY (MemberEmail) 
    REFERENCES Members(Email)
    ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB;

CREATE TABLE IF NOT EXISTS `Rankings` (
  `Platform` VARCHAR(100) NOT NULL,
  `Date` DATE NOT NULL,
  `SneakerName` VARCHAR(100) NOT NULL,
  `Mentions` INT UNSIGNED NOT NULL,
  CONSTRAINT `PK_Rankings`
    PRIMARY KEY (Platform, Date, SneakerName),
  CONSTRAINT `FK_Rankings_Sneakers`
    FOREIGN KEY (SneakerName)
    REFERENCES Sneakers(Name)
    ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB;

以下是一些用于某些情况下检索数据的示例SQL查询：


/* Get All Sneakers Watched by a Member */
SELECT S.Name, S.Price, S.Brand
FROM Sneakers S
INNER JOIN Watchlist W
ON S.Name = W.SneakerName
WHERE W.MemberEmail = '$email'; /* $email is a PHP variable here */

/* Get the 5 Most Mentioned Sneakers In the Last Week */
SELECT S.Name, S.Price, S.Brand, RS.TotalMentions
FROM Sneakers S
INNER JOIN
(
  SELECT R.SneakerName, SUM(Mentions) AS TotalMentions
  FROM Rankings R
  WHERE R.Date > DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
  GROUP BY R.SneakerName
  ORDER BY TotalMentions DESC
  LIMIT 5
) RS
ON S.Name = RS.SneakerName;

学习

概括地说，我们使用实体关系模型根据需求设计了一个关系数据库，以便在实现之前可视化我们的数据库。我学习了如何通过基数来表达数据关系，以及如何重构多对多关系，以使其在SQL中能很好地工作。尽管创建ER图可能很繁琐，但这是验证我们的设计决策以避免以后简单的依赖关系或冗余问题的重要过程。我一直在不断学习有关SQL的更多信息，本文详细介绍了在PHP中实现该项目后的迭代过程。

数据归一化

话虽如此，由于我们需要的实体数量很少，因此我们正在使用一个相对简单的模型，并且没有遇到更多需要更多规范化技术的问题。我避免在帖子中使用该术语，因为它本身是一个复杂的话题，而且仅通过一个重构步骤，我们就能够以Boyce-Codd Normal Form（BCNF）实现数据模型。如果您打算学习有关数据库的更多信息，建议您研究一下不同的范式和规范化技术，以及关系代数和关系演算，以更有效地表达您的SQL查询。