3.4 功能模块设计。
3.4.1 用户注册、登录模块设计。
用户注册、登录模块是整个音乐系统的基础功能之一。
当游客访问网站时，将会进入主页面，此时可以浏览音乐信息及看到热门推荐。
如果目前访问的用户已经在网站注册，那么该用户就可以点击"登录"进入登录页面，在此页面可以输入用户名、密码尝试登陆，用户输入完成后点击登录提交个人信息，如果用户填写的信息与数据库表数据匹配成功，就会跳转到主页面，此时用户的身份由游客转变成注册用户。如果匹配失败，那么将会弹出对话框提示登录失败，要求用户继续尝试。
如果此用户还没有在网站注册过，想要注册账户，可以点击"注册"进入注册页面。在此页面中，用户需要填写用户名（唯一表示，不能与数据库中其它已注册用户重复）、用户密码、个人兴趣偏好（可以多选）等必要信息，填写完成后提交。如果用户提交信息符合注册要求，直接跳转到个人主页面。如果用户提交的注册信息不规范（如 ID 冲突、密码不符合规范等），则将返回注册界面，并提示注册信息错误，让用户重新填写。
以上流程就是是用户注册、登陆模块的功能逻辑设计，注册用户登录成功后的功能。
注册用户登陆成功后的功能示意图。当用户登陆成功后，可以看到以总播放次数为依据进行推荐的热门推荐，其次是根据用户注册时填写的个人兴趣偏好标签及用户历史播放记录、收藏记录等信息综合推荐的个性化推荐页面。
用户可以在推荐列表中查询是否含有自己喜欢的音乐，选择播放进行欣赏。同时，注册用户还有其它功能：
1） 进入个人信息管理页面：在这里，用户可以更改密码、昵称等信息，但不能更改注册标识项（用户名）；2） 如果热门推荐和个性化推荐中没有找到喜欢的音乐，用户可以使用右侧的分类标签更准确的查询喜欢的音乐。
3） 用户可以收藏喜欢的音乐或者对曾经播放、收藏过的音乐评分，也可以从收藏中删除某一首音乐；4） 播放音乐：如果用户找到喜欢的音乐，可以点击"播放"进行欣赏；在上述几个流程中，每当用户进行操作时，如播放、收藏音乐，更改个人偏好标签，或者跟新收藏时，相关的数据信息会自动更新到相应的数据库中，每当用户点击热门推荐、个性推荐页面时，系统会根据最新的数据库信息重新生成推荐，保证推荐内容的准确性。
3.4.2 系统推荐模块设计。
在设计和实现本文的音乐推荐系统时，首先使用了基于内容的推荐算法进行初步的过滤，防止冷启动等问题，之后再使用协同过滤推荐算法。混合过滤推荐算法顾名思义就是两种算法的结合，根据具体使用情况的不同可以划分为两种：
根据不同的使用条件将协同过滤算法或基于内容的推荐算法分别进行，结合起来达到目的的组合式推荐算法，以及将某一种算法放到另一种推荐算法的推荐过程中，最终实现目标的融合式推荐。本文的系统是采用混合式推荐。
事实上，无论使用哪一种推荐算法，用户相似度都是需要首先计算的，使用用户相似度的值可以判断用户是否是新用户或者不太活跃的用户，在用户为新注册用户或该用户的活跃度较低的情况，使用基于内容的推荐算法推荐音乐。
具体设计时，当用户登录成功后，系统就采集用户近期的历史信息，计算该用户的相似矩阵，如果与该用户相似值大于某个规定值的相似用户个数超过指定数目（5 个），即用户的近似度较高的用户（友好用户）比较多，则认为用户是"活跃用户".这种情况下访问数据库，读取该用户个人信息和历史记录，并使用协同过滤算法进行音乐推荐（这里实际上是假设网站的用户总数达到了一定的规模，并且用户的爱好分布较为平均）。
（一）协同过滤算法（Collaborative Filtering recommendation）是目前最受电商业务欢迎的推荐算法之一[24]
,自从 20 世纪 90 年代提出以来得到广泛应用，发展出各种各样的基于协同过滤的变种算法。它的原理是计算用户的偏好，查找偏好相似的其它用户[25]
,以此为基础对音乐信息进行过滤和筛选。
算法的基础思想是：有相同或相似的偏好的用户对某一音乐的偏好可能相同，同基于内容的推荐算法相比，协同过滤算法最突出的特点是他不仅仅关注用户个人信息，还会兼顾那些与用户爱好接近的客户群的兴趣进行联合推荐，能够显着地提升推荐结果的准确性。
这种算法总体而言就是基于一种假设：假如两个用户 A 和 B 对 a、b、c 这三首音乐的评分非常接近，我们就可以假设二者的爱好接近，如果 A 用户还对 d音乐的评分比较高，则可以用户 B 也可能对 d 感兴趣。显然，考虑的近似用户越多，近似度阈值设置的越高，过滤出来的友好用户的相似性就越高，推荐的结果也越准确。
协同过滤算法的基础是用户对音乐的评分，其基本流程是：
如果当前用户对某首音乐 k 没有评分，则寻找与他偏好最相似的 m 个用户，然后从评分矩阵中读取这些用户对 k 的评分的加权平均值，作为当前用户对 k 的评分值，最终决定是否向用户推荐。下图是一个用户评分矩阵：
Rij标识用户 i 对音乐 j 的评分，在本文中，这个值是使用用户 i 播放音乐 j 的次数及是否收藏音乐 j、是否评价了 j 来计算总体评分，协同过滤算法的核心就是如何高效、准确的从用户-评分矩阵中找出相似用户；可以看到，音乐的数量越多，这个评分矩阵就越稀疏，即有可能有些客户对很多音乐没有进行评分。另外，用户参与评分的音乐毕竟只是整个网站的音乐的一小部分，可以预见随着网站音乐总数的不断增长，未评分的音乐会越来越多，用户评价过的音乐所占比例会越来越低，在这种情况下用普通的向量相似度度量算法来计算几个用户的近似度就会不太准确本文采取一种改进的推荐方法来比较两个用户间的相似度。
直接使用余弦相似度算法查找出图3.10中的m-1个与用户中近似度最高的用户，从理论上讲是没有什么问题的，但是实际操作时，如果用户总数、及音乐总数的增加，矩阵十分庞大的情况下，为了找出近似度最高的用户，就必须把所有符合条件的用户都计算一遍，耗时太长。
音乐-用户反向矩阵直观地反映了某首音乐 Mx都有哪些用户浏览过。其中 M 表示所有用户曾经关注过的音乐（包括播放、收藏、评分过的），上图中 0 表示对应的用户没有评价过该音乐，1 表示评价过。根据这个图，我们可以把那些与登陆用户一首共同关注的音乐的用户排除掉，将 3.10 的矩阵过滤为只包含与用户至少有一首共同关注的音乐的用户，一定程度上限定了查找出的用户偏好与当前用户偏好有相似性。因为这种矩阵理论上讲只有当用户、音乐的数目都十分庞大时才有较高的推荐价值，本文中只是用这个矩阵加了一层过滤，提高了推荐度效率。
可以看出来，在这种推荐算法中，最严重的依然是当数据量太多时的性能下降的问题[26]
,因为当前用户可以浏览了大量的音乐，但是可能只是随意的播放了一次，这样的的音乐可能用户的喜欢程度并不高，也就是说音乐-用户反向矩阵虽然可以过滤掉那些和用户相似度为零的用户，但剩下的用户依然有许多无效的用户，为了降低这一问题的影响，使用 JaccardSimilarity 方法再次过滤下近似用户：
得到用户评分矩阵后，以此为依据查找用户的最近邻用户，首先使用JaccardSimilarity 方法来过滤下评分矩阵，JaccardSimilarity 方法的基本思路就是两个用户 m、n 的评分集合的交集除以二者的并集|S ∩ T|/|S ∪ T|,如图 3.12:
其中 S 是用户 m 评价过的音乐的集合，T 是用户 n 评价过的音乐的集合，使用 JaccardSimilarity 方法的目的是排除掉那些与用户有一定的相似度但是相似度太低其他用户，减少下一步计算相似度的计算量，毕竟|S ∩ T|/|S ∪ T|的值越小，意味着两个用户浏览过共同音乐越少，也就说明这两人的偏好不同的可能性越大，如果不把这种情况排除掉，详细计算二者的相似度，得到的数值会是个非常小的数字，对于协同推荐的作用微乎其微。
将|S ∩ T|/|S ∪ T|的阈值设置为 0.2,只有那些相似度大于这一数据的用户才继续参与下一步的相似度计算。本文设计系统的总体音乐量较少，用户数目也较少，因此将阈值设计的比较小，如果是大型网站，收藏音乐总量较多且注册用户数目也比较多的情况下可以将 S、T 中音乐数扩大，并且将阈值设置的大一点，接近或等于 1,这样会过滤更多的用户，剩下的用户相似度极高，再次使用下文中的协同过滤推荐其结果的准确度更高。
因为之前用当前用户的音乐过滤了用户，所以这时的音乐-用户矩阵（图3.11）中，对每一首音乐，当前用户 u 对应的评分一定不是零，正常情况应该是将同一首音乐对应的用户中所有评分不为 0 的用户的分子加一，但是考虑到评分不为 0 的情况有可能是一个用户给了 10 分（满分），另一个给了 1 分，虽然都有评分，但是实际上二者的偏好近似相反，为了更准确，这里使用 N（v,i）表示对于音乐 i,v 和当前用户 u 的评价的相似度：
N（v,i）=1-（ Rui- Rvi）/10, ··· ··· ··· ··· ··· ··· ··· ··· ··· ···（3.2）Rui、Rv相应表示 u,v 对音乐 i 的打分（0~10），这样余弦相似度算法中的分子就等于所有音乐对应的 N（v,i）的和，相应的可以计算出所选近邻与登陆用户u的最终相似值 ,根据项目的需要选择最相近的k个邻居，用 S（u,K） 表示。这样 S 就是我们最终计算出的近邻用户的集合，我们把其中所有用户喜欢的全部音乐取到，得到 M,从中过滤掉登陆用户已经评价过的。对于剩下的每首音乐 i .
可以看到协同过滤有下列优点：
（1）能够推荐原本无法自动进行内容分析的信息，比如在本文的系统中，如果一首音乐在添加时没有添加任何标签，使用基于内容的过滤算法推荐时无法推荐到该音乐，但使用协同过滤算法时就有可能从近似用户那里推荐过来。
（2）考虑了更多的人文因素，避免纯粹以音乐为中心的缺点。
（3）推荐的新颖性，以及对用户的反馈要求不高，不太依赖用户的评分等，而且系统可以在不断的推荐过程中优化推荐结果，提升推荐结果的准确度。
（4）降低了操作的复杂度，对一些不太愿意参与对网站音乐打分的用户而言，只要他们浏览过页面就可以为他们产生个性化推荐，增加网站的友好度。
正因为如此，协同过滤推荐技术在电子商务中得到了广泛应用，Amazon,CDNow,MovieFinder,都使用协同过滤技术来提高服务质量。但是，协同过滤算法也有其缺点：
（1）用户对音乐的评分矩阵可能会非常稀疏，这样以用户评分为前提计算得到的用户近似度可能不够精确（即稀疏性问题，极端情况下是冷启动）；（2）随着系统中注册用户和音乐的增多，系统的性能会越来越低，尤其是本系中事实上相当于进行了三层协同推荐，其效率下降的会比较快。
（3）如果某一首音乐从来没有任何用户评价过，则这首音乐就不可能被推荐给任何用户（即最初评价问题）。
以上介绍了本文改进后的协同过滤推荐流程，为了弥补其缺陷，下面则介绍基于内容的推荐。
（二）如果当前用户的近邻用户不够多，则使用基于内容的算法为用户进行推荐。
在基于内容推荐的推荐模型中，也要使用用户评分矩阵，不过不考虑用户对音乐的评分、播放次数、是否收藏等信息。在注册用户登录成功后，系统采集该用户的历史浏览记录，并安装音乐分类标签对播放过的音乐进行分类，找出该用户播放次数较高的音乐的分类标签，然后使用这些用户偏好的类别从系统音乐库中找到相对应类别的音乐推荐给用户。
基于内容的推荐算法是按照音乐的特征进行推荐的，只要能得到音乐的信息就能够进行推荐，这种推荐方法实际上与传统的信息检索类似，只需要一定的关键字、关键词就可以进行匹配，这种算法常常利用结构化数据技术，例如建立索引、信息检索技术、检索结果排列和评价等。但与信息检索的区别是：信息检索只是机械的匹配搜索的关键字，直接将符合条件的数据返回，而基于内容的推荐算法则是查找那些符合关键字匹配条件的数据中与用户偏好接近，或者与用户以前喜欢的音乐分类标签接近的结果返回给用户。
基于内容的推荐算法的难点在于文本特征的提取，通常需要使用出现在文本中的词来代表这篇文章，之后使用信息检索中的 tf-idf 算法来计算每个词对应的权重。但是由于本文所设计的推荐系统处理的对象是音乐，音乐本身的特征分类比较容易，比如按类型分为热歌、情歌、民歌等，同样的，还可以按照语种、地区、歌手等进行分类。因此不必要再进行特征提取，只需根据用户浏览历史信息（如播放、收藏过的音乐）构造出用户偏好模型， 计算推荐音乐分类标签与用户兴趣模型的相似度， 将其中最相似的音乐推荐给用户。在本文的系统中，系统首先分析用户已经播放、收藏过的的音乐的分类标签（歌手、语言、时间、地区等），再推荐与这些用户感兴趣的音乐相似度高的其他音乐。基于内容的推荐算法的局限性在于它只是考虑了音乐的一部分特征，不可能提取出所有分类标识，影响推荐结果的准确度。另外它忽略了人文因素，比如用户可能受其他用户的影响，欣赏一些以前没有涉及到的音乐，影响网站新音乐的推广。
系统使用基于内容的推荐算法为 Fred推荐音乐的过程。其中的标签是指音乐的分类标签，包括发行年代、地区、分类。
值得注意的是分类标签有可能有多个，如情歌，民歌，金曲等 ,在推荐时优先使用分类标签，因为考虑到多数用户所选音乐的地区，年代等标签往往相对固定，可能导致这些标签在推荐时起到的作用不大。
如果 Fred 是新注册用户，由于系统中没有浏览历史记录，为其推荐时直接使用用户注册时填写的用户偏好标签来作为关注分类来产生用户评分矩阵，然后按照上图中的流程进行推荐。
当 Fred 不是新用户也不是非活跃用户时，其推荐过程如下：
（1）采集用户历史记录（播放历史，收藏历史），统计用户 Fred 所关注的音乐出现频率最高的分类标签，选出三个标签： a,b,c,这三个标签就可以反映出用户最喜欢的音乐的分类集中在哪些类型中；（2）得到用户 Fred 所关注的音乐分类 a,b,c 后，查询系统音乐库，从中找出与同时包含这三个分类标签的音乐 m 首，如果 m 大于等于 12（个性化推荐页面显示的个数），则从这 m 首音乐中选出播放次数最多的 5 首音乐提交给推荐页面，算法结束。如果 m 小于 12,则将这 m 首音乐暂时反倒"临时推荐列表"中，进入下一步；（3）从 Fred 的三个偏好标签中排除 c,查询系统音乐库，从中找出与同时包含 a,b 两个分类标签的音乐 n 首，如果音乐集合 m+n 的个数大于等于 12,则将该集合返回给推荐页面，算法结束。否则，将新查找出的 n 首音乐也放入"临时推荐列表",进入下一步；（4）从 Fred 的三个偏好标签中排除 b,查询系统音乐库，从中找出与同时包含 a,c 两个分类标签的音乐 k 首，如果音乐集合 m+n+k 的个数大于等于 12,则将该集合返回给推荐页面，算法结束。否则，将新查找出的 k 首音乐也放入"临时推荐列表",进入下一步；（5）从 Fred 的三个偏好标签中排除 a,查询系统音乐库，从中找出与同时包含 c,b 两个分类标签的音乐 j 首，如果音乐集合 m+n+k+j 的个数大于等于 12,则将该集合返回给推荐页面，算法结束。否则，将新查找出的 n 首音乐也放入"临时推荐列表",进入下一步；（6）从系统音乐库中查出当前最热门的音乐 12-（m+n+k+j）首，放入"临时推荐列表",将"临时推荐列表返回给推荐页面。
注：以上的推荐流程中，之所以在以所有的双标识查询结束后依然没有凑够12 首推荐音乐的情况下，不再继续以一个标识为关键字进行查询，是考虑到一个标识命中的音乐的随机性太强，推荐的准确度不高；另外，以上流程的 m+n、m+n+k、m+n+k+j 等在计算集合书目在实际实现时需要判断其中是否有重复的音乐，因为以不同的标签查询时有可能返回相同的音乐，在这里需要排除掉重复值，防止在推荐页面出现重复推荐或者推荐数目不足的情况。
综合上文的内容推荐和协同过滤推荐算法的具体实现，可以看到无论单独使用其中一种推荐算法都有比较明显的缺点，将两种算法结合形成混合推荐，优势互补是一种有效的选择。这样的混合推荐算法不仅能相互弥补各自算法的不足，其推荐准确度也会有显着提升。
以上两种推荐算法结合，按照用户的不同情况采用合适的推荐算法，就组成了本文中的混合推荐。在实际应用时，也发现了一些问题，比如不管采用哪种推荐算法，当前系统中最热门的音乐被推荐到个性化推荐里的概率还是最高的，因此，实际推荐时，还要考虑将包含在热门推荐中的音乐从个性化推荐页面过滤掉。
3.4.3 系统数据库设计。
根据上文中的需求分析，结合算法需求。
其中用户注册时必填的信息有用户名，MD5（密码和名字加密后的数据，为了安全），兴趣标签，标识 ID 由系统分配，User_ favorite 是记录用户的历史收藏，其中标识 ID 是唯一的，年龄在本文中属于选填内容。
表中的 IsAdmin 也可以区分是管理员的权限，系统自带的根用户的权限是True,使用根用户可以添加、删除额外的管理员用户，这些新加的管理员用户可以管理用户、音乐信息，但不可以管理其他管理员用户。
存放着音乐对应的信息、标签、播放次数等，其中播放次数是热门推荐的依据，分类标签和地区、时间等标识是个性化推荐时使用的特征。
3.5 本章小结。
本章详细介绍了本文系统设计初始阶段的需求分析，阐述了音乐管理系统中主要模块及其流程设计，介绍了如何把基于内容的推荐同基于协同过滤推荐这两种算法组合成混合推荐算法和。
给出了本系统的数据库设计，为后续系统的实现提供理论基础。
3.4 功能模块设计。
3.4.1 用户注册、登录模块设计。
用户注册、登录模块是整个音乐系统的基础功能之一。
当游客访问网站时，将会进入主页面，此时可以浏览音乐信息及看到热门推荐。
如果目前访问的用户已经在网站注册，那么该用户就可以点击"登录"进入登录页面，在此页面可以输入用户名、密码尝试登陆，用户输入完成后点击登录提交个人信息，如果用户填写的信息与数据库表数据匹配成功，就会跳转到主页面，此时用户的身份由游客转变成注册用户。如果匹配失败，那么将会弹出对话框提示登录失败，要求用户继续尝试。
如果此用户还没有在网站注册过，想要注册账户，可以点击"注册"进入注册页面。在此页面中，用户需要填写用户名（唯一表示，不能与数据库中其它已注册用户重复）、用户密码、个人兴趣偏好（可以多选）等必要信息，填写完成后提交。如果用户提交信息符合注册要求，直接跳转到个人主页面。如果用户提交的注册信息不规范（如 ID 冲突、密码不符合规范等），则将返回注册界面，并提示注册信息错误，让用户重新填写。
以上流程就是是用户注册、登陆模块的功能逻辑设计，注册用户登录成功后的功能。
注册用户登陆成功后的功能示意图。当用户登陆成功后，可以看到以总播放次数为依据进行推荐的热门推荐，其次是根据用户注册时填写的个人兴趣偏好标签及用户历史播放记录、收藏记录等信息综合推荐的个性化推荐页面。
用户可以在推荐列表中查询是否含有自己喜欢的音乐，选择播放进行欣赏。同时，注册用户还有其它功能：
1） 进入个人信息管理页面：在这里，用户可以更改密码、昵称等信息，但不能更改注册标识项（用户名）；2） 如果热门推荐和个性化推荐中没有找到喜欢的音乐，用户可以使用右侧的分类标签更准确的查询喜欢的音乐。
3） 用户可以收藏喜欢的音乐或者对曾经播放、收藏过的音乐评分，也可以从收藏中删除某一首音乐；4） 播放音乐：如果用户找到喜欢的音乐，可以点击"播放"进行欣赏；在上述几个流程中，每当用户进行操作时，如播放、收藏音乐，更改个人偏好标签，或者跟新收藏时，相关的数据信息会自动更新到相应的数据库中，每当用户点击热门推荐、个性推荐页面时，系统会根据最新的数据库信息重新生成推荐，保证推荐内容的准确性。
3.4.2 系统推荐模块设计。
在设计和实现本文的音乐推荐系统时，首先使用了基于内容的推荐算法进行初步的过滤，防止冷启动等问题，之后再使用协同过滤推荐算法。混合过滤推荐算法顾名思义就是两种算法的结合，根据具体使用情况的不同可以划分为两种：
根据不同的使用条件将协同过滤算法或基于内容的推荐算法分别进行，结合起来达到目的的组合式推荐算法，以及将某一种算法放到另一种推荐算法的推荐过程中，最终实现目标的融合式推荐。本文的系统是采用混合式推荐。
事实上，无论使用哪一种推荐算法，用户相似度都是需要首先计算的，使用用户相似度的值可以判断用户是否是新用户或者不太活跃的用户，在用户为新注册用户或该用户的活跃度较低的情况，使用基于内容的推荐算法推荐音乐。
具体设计时，当用户登录成功后，系统就采集用户近期的历史信息，计算该用户的相似矩阵，如果与该用户相似值大于某个规定值的相似用户个数超过指定数目（5 个），即用户的近似度较高的用户（友好用户）比较多，则认为用户是"活跃用户".这种情况下访问数据库，读取该用户个人信息和历史记录，并使用协同过滤算法进行音乐推荐（这里实际上是假设网站的用户总数达到了一定的规模，并且用户的爱好分布较为平均）。
（一）协同过滤算法（Collaborative Filtering recommendation）是目前最受电商业务欢迎的推荐算法之一[24]
,自从 20 世纪 90 年代提出以来得到广泛应用，发展出各种各样的基于协同过滤的变种算法。它的原理是计算用户的偏好，查找偏好相似的其它用户[25]
,以此为基础对音乐信息进行过滤和筛选。
算法的基础思想是：有相同或相似的偏好的用户对某一音乐的偏好可能相同，同基于内容的推荐算法相比，协同过滤算法最突出的特点是他不仅仅关注用户个人信息，还会兼顾那些与用户爱好接近的客户群的兴趣进行联合推荐，能够显着地提升推荐结果的准确性。
这种算法总体而言就是基于一种假设：假如两个用户 A 和 B 对 a、b、c 这三首音乐的评分非常接近，我们就可以假设二者的爱好接近，如果 A 用户还对 d音乐的评分比较高，则可以用户 B 也可能对 d 感兴趣。显然，考虑的近似用户越多，近似度阈值设置的越高，过滤出来的友好用户的相似性就越高，推荐的结果也越准确。
协同过滤算法的基础是用户对音乐的评分，其基本流程是：
如果当前用户对某首音乐 k 没有评分，则寻找与他偏好最相似的 m 个用户，然后从评分矩阵中读取这些用户对 k 的评分的加权平均值，作为当前用户对 k 的评分值，最终决定是否向用户推荐。下图是一个用户评分矩阵：
Rij标识用户 i 对音乐 j 的评分，在本文中，这个值是使用用户 i 播放音乐 j 的次数及是否收藏音乐 j、是否评价了 j 来计算总体评分，协同过滤算法的核心就是如何高效、准确的从用户-评分矩阵中找出相似用户；可以看到，音乐的数量越多，这个评分矩阵就越稀疏，即有可能有些客户对很多音乐没有进行评分。另外，用户参与评分的音乐毕竟只是整个网站的音乐的一小部分，可以预见随着网站音乐总数的不断增长，未评分的音乐会越来越多，用户评价过的音乐所占比例会越来越低，在这种情况下用普通的向量相似度度量算法来计算几个用户的近似度就会不太准确本文采取一种改进的推荐方法来比较两个用户间的相似度。
直接使用余弦相似度算法查找出图3.10中的m-1个与用户中近似度最高的用户，从理论上讲是没有什么问题的，但是实际操作时，如果用户总数、及音乐总数的增加，矩阵十分庞大的情况下，为了找出近似度最高的用户，就必须把所有符合条件的用户都计算一遍，耗时太长。
音乐-用户反向矩阵直观地反映了某首音乐 Mx都有哪些用户浏览过。其中 M 表示所有用户曾经关注过的音乐（包括播放、收藏、评分过的），上图中 0 表示对应的用户没有评价过该音乐，1 表示评价过。根据这个图，我们可以把那些与登陆用户一首共同关注的音乐的用户排除掉，将 3.10 的矩阵过滤为只包含与用户至少有一首共同关注的音乐的用户，一定程度上限定了查找出的用户偏好与当前用户偏好有相似性。因为这种矩阵理论上讲只有当用户、音乐的数目都十分庞大时才有较高的推荐价值，本文中只是用这个矩阵加了一层过滤，提高了推荐度效率。
可以看出来，在这种推荐算法中，最严重的依然是当数据量太多时的性能下降的问题[26]
,因为当前用户可以浏览了大量的音乐，但是可能只是随意的播放了一次，这样的的音乐可能用户的喜欢程度并不高，也就是说音乐-用户反向矩阵虽然可以过滤掉那些和用户相似度为零的用户，但剩下的用户依然有许多无效的用户，为了降低这一问题的影响，使用 JaccardSimilarity 方法再次过滤下近似用户：
得到用户评分矩阵后，以此为依据查找用户的最近邻用户，首先使用JaccardSimilarity 方法来过滤下评分矩阵，JaccardSimilarity 方法的基本思路就是两个用户 m、n 的评分集合的交集除以二者的并集|S ∩ T|/|S ∪ T|,如图 3.12:
其中 S 是用户 m 评价过的音乐的集合，T 是用户 n 评价过的音乐的集合，使用 JaccardSimilarity 方法的目的是排除掉那些与用户有一定的相似度但是相似度太低其他用户，减少下一步计算相似度的计算量，毕竟|S ∩ T|/|S ∪ T|的值越小，意味着两个用户浏览过共同音乐越少，也就说明这两人的偏好不同的可能性越大，如果不把这种情况排除掉，详细计算二者的相似度，得到的数值会是个非常小的数字，对于协同推荐的作用微乎其微。
将|S ∩ T|/|S ∪ T|的阈值设置为 0.2,只有那些相似度大于这一数据的用户才继续参与下一步的相似度计算。本文设计系统的总体音乐量较少，用户数目也较少，因此将阈值设计的比较小，如果是大型网站，收藏音乐总量较多且注册用户数目也比较多的情况下可以将 S、T 中音乐数扩大，并且将阈值设置的大一点，接近或等于 1,这样会过滤更多的用户，剩下的用户相似度极高，再次使用下文中的协同过滤推荐其结果的准确度更高。
因为之前用当前用户的音乐过滤了用户，所以这时的音乐-用户矩阵（图3.11）中，对每一首音乐，当前用户 u 对应的评分一定不是零，正常情况应该是将同一首音乐对应的用户中所有评分不为 0 的用户的分子加一，但是考虑到评分不为 0 的情况有可能是一个用户给了 10 分（满分），另一个给了 1 分，虽然都有评分，但是实际上二者的偏好近似相反，为了更准确，这里使用 N（v,i）表示对于音乐 i,v 和当前用户 u 的评价的相似度：
N（v,i）=1-（ Rui- Rvi）/10, ··· ··· ··· ··· ··· ··· ··· ··· ··· ···（3.2）Rui、Rv相应表示 u,v 对音乐 i 的打分（0~10），这样余弦相似度算法中的分子就等于所有音乐对应的 N（v,i）的和，相应的可以计算出所选近邻与登陆用户u的最终相似值 ,根据项目的需要选择最相近的k个邻居，用 S（u,K） 表示。这样 S 就是我们最终计算出的近邻用户的集合，我们把其中所有用户喜欢的全部音乐取到，得到 M,从中过滤掉登陆用户已经评价过的。对于剩下的每首音乐 i .
可以看到协同过滤有下列优点：
（1）能够推荐原本无法自动进行内容分析的信息，比如在本文的系统中，如果一首音乐在添加时没有添加任何标签，使用基于内容的过滤算法推荐时无法推荐到该音乐，但使用协同过滤算法时就有可能从近似用户那里推荐过来。
（2）考虑了更多的人文因素，避免纯粹以音乐为中心的缺点。
（3）推荐的新颖性，以及对用户的反馈要求不高，不太依赖用户的评分等，而且系统可以在不断的推荐过程中优化推荐结果，提升推荐结果的准确度。
（4）降低了操作的复杂度，对一些不太愿意参与对网站音乐打分的用户而言，只要他们浏览过页面就可以为他们产生个性化推荐，增加网站的友好度。
正因为如此，协同过滤推荐技术在电子商务中得到了广泛应用，Amazon,CDNow,MovieFinder,都使用协同过滤技术来提高服务质量。但是，协同过滤算法也有其缺点：
（1）用户对音乐的评分矩阵可能会非常稀疏，这样以用户评分为前提计算得到的用户近似度可能不够精确（即稀疏性问题，极端情况下是冷启动）；（2）随着系统中注册用户和音乐的增多，系统的性能会越来越低，尤其是本系中事实上相当于进行了三层协同推荐，其效率下降的会比较快。
（3）如果某一首音乐从来没有任何用户评价过，则这首音乐就不可能被推荐给任何用户（即最初评价问题）。
以上介绍了本文改进后的协同过滤推荐流程，为了弥补其缺陷，下面则介绍基于内容的推荐。
（二）如果当前用户的近邻用户不够多，则使用基于内容的算法为用户进行推荐。
在基于内容推荐的推荐模型中，也要使用用户评分矩阵，不过不考虑用户对音乐的评分、播放次数、是否收藏等信息。在注册用户登录成功后，系统采集该用户的历史浏览记录，并安装音乐分类标签对播放过的音乐进行分类，找出该用户播放次数较高的音乐的分类标签，然后使用这些用户偏好的类别从系统音乐库中找到相对应类别的音乐推荐给用户。
基于内容的推荐算法是按照音乐的特征进行推荐的，只要能得到音乐的信息就能够进行推荐，这种推荐方法实际上与传统的信息检索类似，只需要一定的关键字、关键词就可以进行匹配，这种算法常常利用结构化数据技术，例如建立索引、信息检索技术、检索结果排列和评价等。但与信息检索的区别是：信息检索只是机械的匹配搜索的关键字，直接将符合条件的数据返回，而基于内容的推荐算法则是查找那些符合关键字匹配条件的数据中与用户偏好接近，或者与用户以前喜欢的音乐分类标签接近的结果返回给用户。
基于内容的推荐算法的难点在于文本特征的提取，通常需要使用出现在文本中的词来代表这篇文章，之后使用信息检索中的 tf-idf 算法来计算每个词对应的权重。但是由于本文所设计的推荐系统处理的对象是音乐，音乐本身的特征分类比较容易，比如按类型分为热歌、情歌、民歌等，同样的，还可以按照语种、地区、歌手等进行分类。因此不必要再进行特征提取，只需根据用户浏览历史信息（如播放、收藏过的音乐）构造出用户偏好模型， 计算推荐音乐分类标签与用户兴趣模型的相似度， 将其中最相似的音乐推荐给用户。在本文的系统中，系统首先分析用户已经播放、收藏过的的音乐的分类标签（歌手、语言、时间、地区等），再推荐与这些用户感兴趣的音乐相似度高的其他音乐。基于内容的推荐算法的局限性在于它只是考虑了音乐的一部分特征，不可能提取出所有分类标识，影响推荐结果的准确度。另外它忽略了人文因素，比如用户可能受其他用户的影响，欣赏一些以前没有涉及到的音乐，影响网站新音乐的推广。
系统使用基于内容的推荐算法为 Fred推荐音乐的过程。其中的标签是指音乐的分类标签，包括发行年代、地区、分类。
值得注意的是分类标签有可能有多个，如情歌，民歌，金曲等 ,在推荐时优先使用分类标签，因为考虑到多数用户所选音乐的地区，年代等标签往往相对固定，可能导致这些标签在推荐时起到的作用不大。
如果 Fred 是新注册用户，由于系统中没有浏览历史记录，为其推荐时直接使用用户注册时填写的用户偏好标签来作为关注分类来产生用户评分矩阵，然后按照上图中的流程进行推荐。
当 Fred 不是新用户也不是非活跃用户时，其推荐过程如下：
（1）采集用户历史记录（播放历史，收藏历史），统计用户 Fred 所关注的音乐出现频率最高的分类标签，选出三个标签： a,b,c,这三个标签就可以反映出用户最喜欢的音乐的分类集中在哪些类型中；（2）得到用户 Fred 所关注的音乐分类 a,b,c 后，查询系统音乐库，从中找出与同时包含这三个分类标签的音乐 m 首，如果 m 大于等于 12（个性化推荐页面显示的个数），则从这 m 首音乐中选出播放次数最多的 5 首音乐提交给推荐页面，算法结束。如果 m 小于 12,则将这 m 首音乐暂时反倒"临时推荐列表"中，进入下一步；（3）从 Fred 的三个偏好标签中排除 c,查询系统音乐库，从中找出与同时包含 a,b 两个分类标签的音乐 n 首，如果音乐集合 m+n 的个数大于等于 12,则将该集合返回给推荐页面，算法结束。否则，将新查找出的 n 首音乐也放入"临时推荐列表",进入下一步；（4）从 Fred 的三个偏好标签中排除 b,查询系统音乐库，从中找出与同时包含 a,c 两个分类标签的音乐 k 首，如果音乐集合 m+n+k 的个数大于等于 12,则将该集合返回给推荐页面，算法结束。否则，将新查找出的 k 首音乐也放入"临时推荐列表",进入下一步；（5）从 Fred 的三个偏好标签中排除 a,查询系统音乐库，从中找出与同时包含 c,b 两个分类标签的音乐 j 首，如果音乐集合 m+n+k+j 的个数大于等于 12,则将该集合返回给推荐页面，算法结束。否则，将新查找出的 n 首音乐也放入"临时推荐列表",进入下一步；（6）从系统音乐库中查出当前最热门的音乐 12-（m+n+k+j）首，放入"临时推荐列表",将"临时推荐列表返回给推荐页面。
注：以上的推荐流程中，之所以在以所有的双标识查询结束后依然没有凑够12 首推荐音乐的情况下，不再继续以一个标识为关键字进行查询，是考虑到一个标识命中的音乐的随机性太强，推荐的准确度不高；另外，以上流程的 m+n、m+n+k、m+n+k+j 等在计算集合书目在实际实现时需要判断其中是否有重复的音乐，因为以不同的标签查询时有可能返回相同的音乐，在这里需要排除掉重复值，防止在推荐页面出现重复推荐或者推荐数目不足的情况。
综合上文的内容推荐和协同过滤推荐算法的具体实现，可以看到无论单独使用其中一种推荐算法都有比较明显的缺点，将两种算法结合形成混合推荐，优势互补是一种有效的选择。这样的混合推荐算法不仅能相互弥补各自算法的不足，其推荐准确度也会有显着提升。
以上两种推荐算法结合，按照用户的不同情况采用合适的推荐算法，就组成了本文中的混合推荐。在实际应用时，也发现了一些问题，比如不管采用哪种推荐算法，当前系统中最热门的音乐被推荐到个性化推荐里的概率还是最高的，因此，实际推荐时，还要考虑将包含在热门推荐中的音乐从个性化推荐页面过滤掉。
3.4.3 系统数据库设计。
根据上文中的需求分析，结合算法需求。
其中用户注册时必填的信息有用户名，MD5（密码和名字加密后的数据，为了安全），兴趣标签，标识 ID 由系统分配，User_ favorite 是记录用户的历史收藏，其中标识 ID 是唯一的，年龄在本文中属于选填内容。
表中的 IsAdmin 也可以区分是管理员的权限，系统自带的根用户的权限是True,使用根用户可以添加、删除额外的管理员用户，这些新加的管理员用户可以管理用户、音乐信息，但不可以管理其他管理员用户。
存放着音乐对应的信息、标签、播放次数等，其中播放次数是热门推荐的依据，分类标签和地区、时间等标识是个性化推荐时使用的特征。
3.5 本章小结。
本章详细介绍了本文系统设计初始阶段的需求分析，阐述了音乐管理系统中主要模块及其流程设计，介绍了如何把基于内容的推荐同基于协同过滤推荐这两种算法组合成混合推荐算法和。
给出了本系统的数据库设计，为后续系统的实现提供理论基础。
