关系模型

这个系列是学习《Flask Web开发:基于Python的Web应用开发实战》的部分笔记 对于用户提交的信息，包括 账号、文章 等，需要能够将这些数据保存下来 持久存储的三种方法： 文件：shelve(pickle 和 DBM 的结合)等，提供类似字典的对象接口 关系型数据库(SQL) 非关系型数据库(NoSQL) 其他 通常会使用数据库保存信息，并向数据库发起查询获取信息 SQL，关系型数据库 关系型数据库把数据存储在表中,表在程序中通过 Python 的类实现。例如,订单管理程序的数据库中可能有表 customers、products 和 orders。 表的列数是固定的,行数是可变的。 列 定义表所表示的实体的 数据属性 。例如,customers表中可能有 name、address、phone 等列。表中的 行 定义各列对应的 真实数据 。 表中有个特殊的列,称为 主键 ,其值为表中 各行的唯一标识符 。表中还可以有称为 外键 的列,引用 同一个表或不同表 中 某行的主键 。行之间的这种联系称为 关系 ,这是关系型数据库模型的基础。 从这个例子可以看出,关系型数据库存储数据很高效,而且 避免了重复 。将这个数据库中的用户角色重命名也很简单,因为角色名只出现在一个地方。一旦在 roles 表中修改完角色名,所有通过 role_id 引用这个角色的用户都能立即看到更新。

对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销；然而，如果ORM作为一种中间件实现，则会有很多机会做优化，而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理；但是同样，这些花费要比维护手写的方案要少；而且就算是遵守ODMG规范的对象数据库依然需要类级别的元数据。 对象-关系映射（Object/Relation Mapping，简称ORM），是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。 面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的

文章目录 1.数据模型 2.关系模型与非关系模型 2.1 关系模型、文档模型与图模型 2.2 层次模型的局限与演化 2.3 文档数据库的模式灵活性与数据局部性 读时模式 VS 写时模式 数据局部性的优缺点 2.4 MapReduce查询 3. 图模型 3.1 属性图模型和Cypher查询语言 属性图的基本概念 3.2 三元存储模型与SPARQL查询语言 RDF数据模型 SPARQL查询语言 3.3 一阶谓词逻辑表示法与Datalog 一阶谓词逻辑 Prolog语言 3.4 图数据库与网络模型的比较 1.数据模型 大多数应用程序是通过一层一层叠加数据模型来构建的，每一层都面临的关键问题是：如何将其用下一层来表示？例如： 1. 观察现实世界，通过构建对象或数据结构，以及操作这些数据结构的API来对其建模。 2. 采用通用数据模型，存储这些数据结构。 3. 数据库工程师决定用何种内存、磁盘或网络的字节格式来表示上述数据。 4. 更下层，硬件工程师考虑如何用电流、磁场、光脉冲等来表示字节。 基本思想相同：每层都通过提供一个简洁的数据模型来隐藏下层的复杂性。这种抽象机制使得不同的人群可以高效协作。 2.关系模型与非关系模型 关于NoSQL的介绍，与SQL的对比，没有比这个介绍更准确详细了，请参照菜鸟教程： NoSQL简介 本书中主要介绍和研究的非关系模型是：文档模型、图模型

过去的一段时间里，忙于考试、忙于完成实验室 要求的任务 、更忙于过年，很长时间没有以一种良好的心态来回忆、总结自己所学的东西了。这几天总在想，我应该怎么做。后来我才明白，应该想想我现在该做什么，所以我开始写这篇博客了。这将是对概率图模型的一个很基础的总结，主要参考了《PATTERN RECOGNITION and MACHINE LEARNING》。看这部分内容主要是因为 LDPC码 中涉及到了相关的知识。概率图模型本身是值得深究的，但我了解得不多，本文就纯当是介绍了，如有错误或不当之处还请多多指教。 0. 这是什么？ 很多事情是具有不确定性的。人们往往希望从不确定的东西里尽可能多的得到确定的知识、信息。为了达到这一目的，人们创建了概率理论来描述事物的不确定性。在这一基础上，人们希望能够通过已经知道的知识来推测出未知的事情，无论是现在、过去、还是将来。在这一过程中，模型往往是必须的，什么样的模型才是相对正确的？这又是我们需要解决的问题。这些问题出现在很多领域，包括模式识别、差错控制编码等。 概率图模型是解决这些问题的工具之一。从名字上可以看出，这是一种或是一类模型，同时运用了概率和图这两种数学工具来建立的模型。那么，很自然的有下一个问题 1. 为什么要引入概率图模型？ 对于一般的统计推断问题，概率模型能够很好的解决，那么引入概率图模型又能带来什么好处呢？

基于 RBAC 的权限设计模型： 1 RBAC 介绍 RBAC 模型作为目前最为广泛接受的权限模型。 NIST （ The National Institute of Standards and Technology ，美国国家标准与技术研究院）标准 RBAC 模型由 4 个部件模型组成，这 4 个部件模型分别是基本模型 RBAC0 （ Core RBAC ）、角色分级模型 RBAC1 （ Hierarchal RBAC ）、角色限制模型 RBAC2 （ Constraint RBAC ）和统一模型 RBAC3 （ Combines RBAC ） [1] 。 RBAC0 模型如图 1 所示。 图表 1 RBAC 0 模型 l RBAC0 定义了能构成一个 RBAC 控制系统的最小的元素集合 在 RBAC 之中 , 包含用户 users(USERS) 、角色 roles(ROLES) 、目标 objects(OBS) 、操作 operations(OPS) 、许可权 permissions(PRMS) 五个基本数据元素，权限被赋予角色 , 而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话 sessions 是用户与激活的角色集合之间的映射。 RBAC0 与传统访问控制的差别在于增加一层间接性带来了灵活性， RBAC1 、 RBAC2 、 RBAC3

面向对象(Object Oriented,简称OO)是当前计算机界关心的重点，它是90年代软件开发方法的主流。面向对象的概念和应用已超越了程序设计和软件开发，扩展到很宽的范围。如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构、CAD 技术 、人工智能等领域。 表面来看，面向对象这个术语的意思是，把软件组织成一系列离散的，合并了数据结构和行为的对象。这与以前软件开发方法中数据结构和行为只是松散关联是不同的。关于OO方法确切需要哪些特征学术界是有争议的，但大致上它们都包含四个方面：标识（identity），分类(classification) ，继承(inheritance)，多态(polymorphism)。 标识：数据被量化成称为对象的离散的，可辨别的实体。每个对象都有它自己的内部标识。换言之，即使所有的属性都相同，两个对象也是有差别的。 分类：拥有相同数据结构（属性）和行为（操作）的对象被分组成为一个类。 继承：多个类基于一种分层关系，共享类间的属性和操作（合称为特征）。 多态：对于不同的类来说相同的操作会有不同的动作。 面向对象的基本概念： (1)对象。 对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。 (2)对象的状态和行为。 对象具有状态，一个对象用数据值来描述它的状态。

本文翻译自 The Flask Mega-Tutorial Part VIII: Followers 这是Flask Mega-Tutorial系列的第八部分，我将告诉你如何实现类似于Twitter和其他社交网络的“粉丝”功能。 在本章中，我将更多地使用应用的数据库。 我希望应用的用户能够轻松便捷地关注其他用户。 所以我要扩展数据库，以便跟踪谁关注了谁，这比你想象的要难得多。 本章的GitHub链接为： Browse , Zip , Diff . 深入理解数据库关系 我上面说过，我想为每个用户维护一个“粉丝”用户列表和“关注”用户列表。 不幸的是，关系型数据库没有列表类型的字段来保存它们，那么只能通过表的现有字段和他们之间的关系来实现。 数据库已有一个代表用户的表，所以剩下的就是如何正确地组织他们之间的关注与被关注的关系。 这正是回顾基本数据库关系类型的好时机： 一对多 我已经在 第四章 中用过了一对多关系。这是该关系的示意图（译者注：实际表名分别为user和post）： 用户和用户动态通过这个关系来关联。其中，一个用户拥有 多 条用户动态，而一条用户动态属于 一 个用户（作者）。数据库在 多 的这方使用了一个 外键 以表示一对多关系。在上面的一对多关系中，外键是 post 表的 user_id 字段，这个字段将用户的每条动态都与其作者关联了起来。 很明显， user_id

一、深度强化学习的泡沫 2015年，DeepMind的Volodymyr Mnih等研究员在《自然》杂志上发表论文Human-level control through deep reinforcement learning[1]，该论文提出了一个结合深度学习（DL）技术和强化学习（RL）思想的模型Deep Q-Network(DQN)，在Atari游戏平台上展示出超越人类水平的表现。自此以后，结合DL与RL的深度强化学习（Deep Reinforcement Learning, DRL）迅速成为人工智能界的焦点。 过去三年间，DRL算法在不同领域大显神通：在视频游戏[1]、棋类游戏上打败人类顶尖高手[2,3]；控制复杂的机械进行操作[4]；调配网络资源[5]；为数据中心大幅节能[6]；甚至对机器学习算法自动调参[7]。各大高校和企业纷纷参与其中，提出了眼花缭乱的DRL算法和应用。可以说，过去三年是DRL的爆红期。DeepMind负责AlphaGo项目的研究员David Silver喊出“AI = RL + DL”，认为结合了DL的表示能力与RL的推理能力的DRL将会是人工智能的终极答案。 RL论文数量迅速增长[8] 1.1 DRL的可复现性危机 然而，研究人员在最近半年开始了对DRL的反思。由于发表的文献中往往不提供重要参数设置和工程解决方案的细节，很多算法都难以复现

知识图谱的构建技术与应用研究 知识图谱的概念在2012年由Google正式提出，其目的是以此为基础构建下一代智能化的搜索引擎，改善搜索结果质量。知识图谱技术是人工智能技术的重要组成部分，也是当下非常热门的研究方向。文章从知识图谱的概念和技术架构出发，综述知识图谱构建的关键技术，包括知识抽取、知识表示、知识融合、知识推理四大主要内容。同时，对于知识图谱的当下的现实应用作进一步阐述。 目录 1知识图谱概述 2知识图谱构建技术 2.1知识抽取 2.1.1实体抽取 2.1.2关系抽取 2.1.3属性抽取 2.2知识表示 2.2.1代表模型 2.2.2复杂关系模型 2.2.3多源信息融合 2.3知识融合 2.3.1实体链接 2.3.2知识合并 2.4知识推理 3知识图谱的应用 3.1智能搜索 3.2问答系统 3.3社交网络 3.4垂直应用 4总结 参考文献 1知识图谱概述     说起知识图谱，不由得从信息检索开始，从本质上来说，知识图谱是信息检索新时期的产物。信息检索起源于图书馆的参考咨询和文摘索引工作，19 世纪下半叶开始起步，至 20 世纪 40 年代，索引和检索成为图书馆独立的工具和用户服务项目。信息检索是知识管理的核心支撑技术，伴随知识管理的发展和普及，应用到各个领域，成为人们日常工作生活的重要组成部分[1]。伴随着Web技术的不断演进与发展，人类先后经历了以文档互联为主要特征的

转自： https://www.cnblogs.com/yijiahao/p/11707183.html E-R模型如何转换成关系模型，这里我们分成三种情况进行讲解，分别是一对一，一对多和多对多。 1.一对一的情况： 　　有两种方法解决这个问题。 第一个方法： 可以单独对应一个关系模式，由各实体的主码构成关系模式，而关系模式的主码可以是任一个实体集的主码。而实体中属性照常写就可以了。 第二个方法： 实体中的属性照常写，然后将一方实体集的主码加到另一方实体集对应的关系模式中。下面举个例子我们来看一下： 在这个例子中，利用方法一，先将两个实体正班长和班级的属性照着写下来，然后将关系模式“属于”的属性写出来——即两边实体的主码，其中关系模型“属于”的主键可以是两端实体集的任一主码。利用方法二，也是先将两端实体的属性照着写下来，然后注意这一点，将一端实体的主码加到另一端实体的主码中，图例中就是将“班级”实体的主码加入到“正班长”关系属性中。 2.一对多的情况： 　　这种情况可以跟一对一的情况对比着学习。 第一个方法： 同一对一的方法一是差不多的，只是对应的关系模式中，其主码不再是任一实体的主码就可以，而是必须指定n端的主码为关系模式的主码。 第二个方法： 同一对一的方法二也是差不多的，但是值得强调的是，必须将1端的主码加到n端的关系模式中，而且n端的主码仍然为该关系模式中的主码。同样