未来社会模型中 SaaS 的位置与分量
上图是一个从连接这个透视角度抽象出来的社会模型，其中的家庭、人、组织、物都是相互连接的，它也是一个从软件架构抽象出来的社会模型。SaaS 是对软件的获得和使用方式的革命，早在 2004 年就已有端倪（当时称为 ASP，Application Service Provider）。笔者认为，可以将 SaaS 放在社会运行机制、发展趋势这样的大格局中定位其社会作用。SaaS 企业也需要这样的格局与信念，虽然在中国还没有出现非常成功的 SaaS 企业，但终究会出现的，信任、习惯、规范、与能力都需要进化，需要时间。
在没有电之前，人们就有传递信息的需求，这也是为什么微信能够存在的本质根由。同理，各种组织都离不开软件，而且软件的渗透越来越广泛与深入，因为整个世界的数字化是不可阻挡的趋势。而 SaaS 在大部分情况下是必选之路，会越来越成为标配，除非特殊原因，或者不在乎成本、或者已经拥有某种等效的软件、或者其他原因。只要这种本质性的需求存在着，社会的发展终究会以越来越先进的方式来满足它。
这里分享一个关于云的小故事，笔者曾经算过一笔账，如果在云上订购托管机房中约 500 台机器的同等算力，每年需要支出 5000 万，相当有悖于流行认知，其实对于稍微有些规模的 IT 资源诉求，云相对是更加昂贵的，但来的快、方便，两方面都是事实。
这里只想传递一个观点，长远来看，SaaS 有它存在与发展的必然性。结构上讲，它是社会运行机制中不可或缺的一部分。同样或者类似的软件，显然没有必要每个人、每个组织都各买一套或各自开发一套，这是社会资源的极大浪费，有悖于社会发展的基本规律——既然是必需的，必然选择物美价廉。而且组织支出比个人支出更理性、更注重实用价值，有利可图的需求终究会达到稳态的、某种主流服务的满足。
从架构角度看 SaaS 面临的挑战
如果说 SaaS 在大部分情况下将会成为必选之路，那么它面临的最大挑战又是什么呢？概括来讲，SaaS 面临的最大挑战是满足客户的个性化需求。从架构角度看，它体现在如下图所示的几个方面：
其中最有挑战性的又要属多变的后台逻辑与数据模型。对于 SaaS 供应商而言，这种需求显然不能通过项目的方式来定制满足，而只有通过提供灵活的自服务平台才能满足，这种灵活性就需要用 PaaS 来生产客户想要的软件。这一点笔者在2013 年做一个 SaaS 项目的架构工作时就深有体会：一开始的目标也是做 SaaS，但是后来还是走上了 PaaS 的道路，不过是专为生产 SaaS 而自用的 PaaS，而不是定位于 PaaS 供应商。
如果一个 SaaS 企业从一开始就只是聚焦某个业务，而没有着手 PaaS 的建设，那说明它在满足个性化需求的道路上一定是在某个局部、某个层面解决问题，而不是系统、全面、可复用地解决问题。同时，从中国 SaaS 市场现状来看，它的成长比较慢，环境的综合成熟度还不够高，聚焦单一业务成长的加速度不够，因此企业后续很可能会从最开始聚焦的核心业务向外扩展，到时候又要面临种种个性化需求问题。因此，一个成功的 SaaS 企业必然要去寻求 PaaS 的支撑。从这两个意义上讲，PaaS 可能也是 SaaS 企业提高生产力的必经方向。据有关数据
表明，在企业弃用 SaaS 的原因中，无法满足个性化需求占了 23%，可见 PaaS 的支撑多么重要。
如何做好 SaaS 架构？
1 业务数据库
SaaS，特别是 To B 的时候，业务数据库必然是存储的核心，这里笔者针对业务数据库总结了一些架构层面的建议。
建议一：对于任何 mission critical 的场景都要使用 RDBMS
企业应用与 To C 的使用场景有一个明显的区别是，绝大部分情况下，它对正确性、准确性的要求更高，而且 SaaS 提供方需要对此承担相应的责任。因此，支撑一线黄金业务流程的数据库目前来看还是得使用关系型数据库。目前来看有两个开源可选项，分别是 MySQL 和 PostgreSQL。
建议二：分库
支持多租户可以有多种方式，这里所说的分库并不是指每个租户一个独立的库（当然产品销售时可以作为套餐的一个选项），而是指多个数据库实例，每个实例包含多个租户的完整数据。
说到多租户，需要提个醒，通常大家都会想当然地认为租户之间是隔离的，但是事情都有另一面，对于大集团客户，在某些业务上，它的分公司、子集团之间可能还是有连接的。另外，人员组织机构建模上，也要考虑一个人任职多个子集团或公司的可能。
建议三：Partitioning
即使是一个数据库实例，也可以再继续分区，MySQL 和 PostgreSQL（至少版本 11 以上）都支持在一个实例内部分区。对租户进行 Partitioning 可以在一定程度上提高性能，因为把一个查询限制在更小的数据范围内进行，而非全量数据空间，效率自然会更高。
建议四：元数据驱动，Salesforce 不是标杆
一个民族、一个国家如果没有非权威精神，是不会有根本性创新的。动则大厂是如何做的，好像大厂总是做的最好的，那是不行的，盲目崇拜只能是 follower，不可能是 creator，当然也不能盲目忽视，最要紧的是把业务架构搞清楚、明确定义到底要什么。心里要有谱，但是技术本身绝对不是谱，而仅仅是可选的手段。
以下是根据 Salesforce官网资料整理的的核心数据模型：
其业务数据表本身是没有物理索引的，真正的索引主要在MT_Indexes 中，但是这有点让人困惑，为什么不在MT_Data 上直接建立物理索引呢？难道列和索引太多了会影响性能？而反范式地单独以列的方式、按数据类型建立很少的索引就好？为此，笔者动手做了验证。
1）实验条件
为了聚焦在问题本身，图 3 中只采用了绿色的两张表，而省略了红色的字段，本实验所使用的字段名和图 3 不一样，但是思路是一样的。
OS，Windows 10；
DB，MySQL 5.7；
两张业务表，有物理索引的 =bizdata，没有物理索引的 =bizdata2，结构如下：
bizdata 和 bizdata2 都灌入了 10 万条数据，字符型长度为 4，它的值基于给定的一个长度为 10 的字符串随机生成，数值型的则为 100 以内的随机数；
索引表为 pivot_index，其中 rowid 的值等于业务表中 id 的值，col 是列名，它们可能的值是 c1-c5、n1-n5，string_value 和 int_value 分别容
纳的是字符型和数值型的业务数据值，总的数据行数是 100 万行。
2）实验结果
以下比较，除了 SQL 形态上不一样，从语义上讲，条件与期望的结果都是完全一样的。汇总如下：
#方式结果（秒）
5.39
1MT_Data（自身无物理索引） +
MT_Indexes，Salesforce 方式
2MT_Data（自身有物理索引）0.05
3MT_Data（自身无物理索引）0.13
0.16
4MT_Data（自身无物理索引），且字符
字段都采用条件 like ‘%xxxx%’
使用 Salesforce 索引表（相当于业务数据表 MT_Data 上没有物理索引，红框部分为行变列的 pivot 逻辑，其实红框外的条件在都是 or 的情况下是可以省略的，否则不可以，这里仅仅为了体现逻辑完整结构，Salesforce 后台用的是 Oracle，也许性能比 MySQL 好不少，也许 Oracle 有 pivot 的核武器，不过从逻辑上讲，就算给 Oracle 更大的想象空间，行数倍增也是不争的事实）的结果：
直接使用物理索引（相当于业务数据表 MT_Data 上有物理索引）的结果：
直接使用没有物理索引的业务数据表（相当于不考虑 MT_Indexes）的结果：
在没有使用物理索引的 bizdata 上用’%xxx%’，看情况如何：
3）实验结论
结论是不要采用 Salesforce 的元数据使用方式，因为其行列转换的性能损失相当大。此例相当于把数据行数放大了 10 倍，显然在业务数据表上直接建索引更可取。当然，Salesforce 的情况可能有其历史原因，或者它有某种未知的核武器。本文建议采用如下模型：
其实，Salesforce 对于查询是有限制的，如果它消耗的资源太大，会直接抛异常。很可能它是依据提取数据的行数的阈值或者时间（governor limits，资源裁判的角色）来限制的，因此它的性能还是有一定的局限性。官网对此表述为：“被优化器认为资源开销过大的个别查询会抛出异常给调用方，尽管这听起来有点严格，但为了保护数据库系统总体的可伸缩性和性能，这是必要的。”
建议五：索引所有字段
Salesforce 的做法是让租户自己决定一个字段是否要索引，但笔者认为在硬件越来越廉价的今天，如果要在用户体验与成本之间平衡，用户体验更可取。不过 Salesforce 也会自动为特定字段建索引，参见这里。
其实软件这东西，从用户接受层面上讲，在根植于中国文化的市场上是有点障碍的。例如：字段field，这个词对于中国大部分普通人来说是很陌生的，但是对于以英语为母语的市场而言，说“请把这个表格填一下”，然后说“包括每一个field”，则是一件很普通的事情。当我们交付一个产品的时候，需要站在用户的角度去体验、思考、感受，而不能假设所有人都有和软件开发人员一样的认知背景。
建议六：PostgreSQL 优于MySQL
这里不是要对二者做详尽的比较，而是瞄准一个核心点，元数据驱动的定制能力。由于MySQL 的row size 是有限制的，65535 字节，而PostgreSQL 的限制则为1GB，显然后者有更广阔的空间，这也是推荐图 10 业务数据模型的原因之一。
建议七：深挖数据库本身的优化空间
对于PostgreSQL，相信还有很多潜力可以挖掘，笔者暂未对其做过深入研究，这里只给出一个方向。例如：它支持sub-partition，假设在用OrgID 分区的前提
下，再进一步用年来分区，对于有些数据的性能可能会更进一步提升，不过无法保证这个可行，凡有得必有失。
再比如，在MySQL 中，通常可能认为插入一条数据没啥可优化的，就是通常见到的那种写法，但是，insert into table_1 set a=a1,b=b2 这样的写法据说是最高效的。
诸如此类，结合多租户、元数据驱动的特点，可能还有很多值得挖掘的地方，最可靠的方法是完整研读官网、对多种值得关注的选项动手试一试。
2 搜索
搜索是 SaaS 必须具备的一种能力，例如：输入关键词，希望系统能找出附件中出现这些关键词的合同，不管附件的格式如何。搜索和通常 RDBMS 的全文检索是完全不同的，尽管在某些技术思路上是一样的，但具体实现的能力差别很大。因此，SaaS 系统必须提供存在于关系型数据库之外单独的搜索系统。
这里仍以 Saleforce 为例展开说明。Salesforce 对于空间非常吝啬，对于任何一个用户自定义字段，是否建索引、是否可以搜索，都把选择权留给用户。其实这么做从用户体验上看并不好，而且对于普通用户，一般对于搜索与查询没有很强的技术性概念，在选择时就会存在困惑。因此，更可取的做法可能是，对于可能需要搜索的，就让它都能搜索。但是，有一个基本的问题要回答，那就是结果集从哪里来？
如果结果集中同时包含来自关系型数据库和搜索引擎的数据，并让用户在定制过程中选择各个字段的结果都从哪里来，对用户体验可能不大好。但我们可以这么做，让最终用户在已经完成定制并发布的功能中选择，在高级查询界面专门开辟出搜索条件区域，让用户输入关键词和搜索范围即可。
上图左侧的模式，搜索引擎返回的是 ID 列表，需要组合两个引擎的能力。这就要求平台有自己的查询引擎和优化器，基本逻辑是先识别出搜索部分，然后把结
果组装到原来的查询语句中，最后提交给 RDBMS 来处理。
这里补充一个建议，对于用户上传的附件，只要可以转换为文本，也把它送到搜索引擎，用户在定义业务实体的时候可以不指定要不要可搜索，但是在构建查询功能的时候，可以由用户来决定是不是对某些字段执行搜索。
由于目前的开源搜索引擎（至少 Elasticsearch 是这样的）还不能保证聚合的准确性和不丢失数据，因此对于潜在的丢失数据的问题，在架构上可以考虑：
3 元数据
把对元数据的理解局限于表及其属性、字段及其属性，是不够的。其实把元数据称为模型驱动更合适，它可以包含 PaaS 或 SaaS 中那些所有由客户自己创建的软件要素的模型，例如：邮件模型、界面模型、布局模型、API 模型、流程模型等。其实人类认识世界、改造世界，根本上就是一个模型提出、验证、运用的过程。这个世界会越来越由数据驱动，背后实际上就越来越是由模型驱动。如果一个 PaaS 或 SaaS 由外到里都是模型驱动的，那它的定制能力一定很强，适应、生存、发展的能力也一定会很强，因为不管需要什么都可以直接用 PaaS 来生产，就像一个超级生产线，非常规范。
关于版本控制，在 PaaS 上定制的一切都可以看作配置，它们都需要版本控制能力，颗粒度可以由粗到细，当然这也要求为用户提供非生产环境，下面会提到。
4 环境
人都有可能犯错，而改变就需要测试和验证，虽然我们赋予了用户定制的能力，但直接修改生产环境可能意味着不可恢复的风险。不论是 SaaS 还是 PaaS，都显然不妥。另外，用户可能自己定制出很复杂的应用，而要用到它的新员工需要培训，可是显然不可能通过实际操作来进行培训。因此，很有必要为客户提供非生产环境，这一点 Salesforce 做得非常到位，值得学习。这也是差异化利润点，其各种环境的主要区别在于有没有生产数据、有多少。
5 后台进程组件
上图中架构的主旨是为了实现零编码，该架构最终实现的 PaaS 的目标受众是 Citizen Developer，即没有 IT 背景的人。也就是说后台逻辑是完全由配置驱动的或者说声明式的，并且要可视化地、以拖拽方式完成后台逻辑的设计。虽然没办法说它能实现所有的后台逻辑（因为理论上逻辑是有无限可能的），但是，它所能做的范围已经可以覆盖绝大部分情况了。有人可能会说，后台逻辑中的循环逻辑、分支逻辑怎么办呢？这也是可配置的。从技术上讲，就如何满足后台的定制需求这一点来讲，Salesforce 有自己的编程语言 Apex、自己的 Query Language 和 Search Language，但个人觉得这都是面向程序员的，不够好，本文建议零编码，真正做到 For Citizen Developer。
当一个请求经过网关到达一个服务进程以后，在这个进程里发生的所有事都是由Process Engine 总控的。其最为核心的抽象是，输入的对象、本地调用或者远程调用返回的结果，或者本地子过程的处理结果都是有名称的、可引用的、可以通过属性路径来操作的对象，而这个对象的结构是任意的，如图中的 input 和 result_*。概括起来讲，就是内存里的所有数据都是声明方式可操作的。
从大的方面看，这个 PaaS 核心架构，有一种情况不能满足，那就是微服务。如果客户要求存储独立的微服务，那是做不到的，对客户的系统设计能力要求相应地也比较高。其实微服务更多是给研发用的，客户一般并不关心。对于一个租户而言，微服务真正有意义的地方在于，业务所要求的数据处理能力已经超出了一个关系型数据库实例的上限。这样的话，可能更可取的方式是，看如何在一个租户范围内实现写操作的分区（可以设计为图 14）。不过那就太大了，如果一个
租户都达到这样一个系统要求的量级了，可能不应该找 SaaS 或 PaaS 供应商，而只能另觅他途了。
作为 SaaS 或 PaaS 供应商，如果用微服务，可以考虑把人员组织机构、第三方服务的调用、报表等独立出来，剩下的都是客户的业务，在单体应用中处理即可。
协议建议采用 HTTP2，它是多工（mutiplex）的，且服务端可推。即使内部使用，因为 HTTP2 已经很快了，足够用，简单就是美。
再稍微提一下区块链，区块链最根本的地方是关于信任的，一般 SaaS 是关于企业内部活动的（intro-company），但是如果 SaaS 供应方把业务扩展到企业之间的行为（inter-company），也许区块链就有用武之地了，而入驻的企业就能变得既隔离又联结。
审计，To B 的应用相对于 To C 的应用往往是更严肃、更讲究责任的，为此，建议至少做到记录级的审计，5W（who/where/when/what/how）。
权限，企业应用离不开权限管理，有没有考虑到集团化的企业呢？多个分公司、子集团，各个分支机构之间在很多领域是相互隔离的，但也有可能是相通的。数据权限怎么处理？能由集团的超级管理员来总控分公司的管理员吗？支持阿米巴组织吗？SaaS 要走远、要做大，诸如此类的问题恐怕是不可避免的，当然可以先放在低优先级去实现，但是在设计上必须支持才好。
6 前端
写到这里，对于个性的满足就剩前端了，这里简单给出建议：
使用与后端相同的数据模型；
封装自己的控件，模型如下图所示，有的时候共享 dataset 会让有些事情处理起来变得很方便，页面内有全局的 dataset 管理就更好了；
On demand，或者懒加载，需要了再请求，不要从后台一次提取页面可能需要的全量数据，其实很多情况下实际是在让后台做无用功；
但凡用户设置的，都在元数据的管理范围之内，要让满足个性化需求这件事情完全由数据驱动的，不管是企业的个性还是用户的个性；
页面内逻辑实现也可以是基于元数据的，也就是说页面内的逻辑也是可定制的，即使实现起来有点复杂。
总结
本文的核心是聚焦于 SaaS 如何满足个性化需求，由此引出 PaaS，并不是定位于成为 PaaS Vendor，后者可能还需要扩展到数据仓库、实时数据仓库、流式计算、机器学习、数据中台、数据应用、图计算、IoT 等方面。不过这些除了选择合适的中间件，在平台中实现连接件，剩下的用户通过自服务实现所需定制构件的方法与文中提到的没有很大差异，换句话说，仅为量变。假设定位为 PaaS Vendor，本文分享的方法也是适用的，每个扩展领域只是商业上值不值的问题。
不过，如果边界划到满足 SaaS 的需要，可以扩展到由用户决定要不要微服务、要不要独立的报表服务（包括独立的库）两个方面。再想提一点的是，做 SaaS，一定要做好与客户既有系统、或可能的外在系统的集成，这对于 SaaS 供应商而言意味着数据双向的流动。
另外，要让系统合规，例如：GDPR 规范，国家标准或行业标准，尤其是数据治理、安全方面，虽然本文已经建议做到记录级的审计，但还是需要认真研究一下
有关标准。
最后想跟大家分享几条架构心得，这些也是笔者在写本文的过程中考虑到的一些思想，虽然和 SaaS 没有直接联系，但假如实践中真的能够以如下思想为纲，必有受益。以下内容不成体系，想哪写哪，希望对大家在思考具体问题的时候能有帮助。
Solve the business problem，不要片面地停留在技术层面，业务战略、业务架构、业务发展诉求的满足等业务层面的认知与探究才是第一位的，要以业务为始、以业务为终；
One place, once for all，最好能够在一个地方、一次性地解决一类问题，而不是头疼医头脚疼医脚，这是衡量一个架构好坏的准绳之一；
站在巨人肩膀上，先学习人家是怎么做的，验证是否效果最好，摈弃权威思维定式；
不是功能有了，就一切都有了，那样到后来很可能就跑不动了。要动手做基础研究，切忌跟风，一定要根据业务自己动脑子思考，心里明白真正要什么，往往真正要的不是框架本身，跑得快、可能欠下很多债，乃至积重难返。火车启动慢，一旦跑起来其能量不是任何摩托车可比的，就像下围棋一样，局布得不好，迟早会为其买单；
业务、业务、抽象、抽象，抽象（abstract）这个词来源于古希腊，意思是去掉细节。不要一开始就太纠结于具体技术、框架，如果思维的焦点大部分都是这些东西，作为架构师是彻底把方向搞反了，其实务虚比务实更重要，如果事情已经推进到了涉及具体技术的阶段，那已经不是大问题了。这并不是说不主张 get your hands dirty on something，而是讲什么更重要、什么是先导、什么服从于什么，这也是为什么一个高端的岗位更需要一个更注重修为、有思想的人；
早先大家用黑白照相机，然后有了彩色相机，现在用手机似乎就可以拍出不错的照片，可是照的好的还是摄影师。这是一个类比，随着技术生态的发展，各种框架不断涌现，就好比是傻瓜相机，但做架构不是去学会如何按那个快门，不是去拼盘、攒框架，如果仅仅是那样，就不是玩技术了，而是被技术玩了。可能有不少人以技艺自居，舍本逐末，不练思维，为技而动，这是做不好架构的。现在网络如此发达，知识唾手可得，就具
体技术而言，不知、不会其实都不是太大的问题，真正的问题是如何全面、透彻地思考业务，然后在纯抽象的层面明确地定义到底要什么、具体的架构目标是什么，然后才进入到技术选型阶段。架构相对于开发是一个谋大于动的工作，做软件不是人越多越好、越强，而是要想着如何用最少的人做更大的事；
做一个强大的 PaaS，完全可以雇一些类似富士康生产线上的人，经过完整培训，然后就可以高效、高质量地生产包括 SaaS 在内的大部分软件了，即使需要承受很大的并发、覆盖复杂的业务逻辑。国内制造业的核心、高端技术，放眼望去，其实挺贫瘠的，软件业更是如此。其实软件的品控远远没有制造业做得好，原因在于最终交付物中个人因素太多了，越多越不可控，而 PaaS 大大限制了开发者的自由裁量权，而且内在逻辑完全是可控的，因此质量一定比通常的开发模式高许多，且会累积性地提高，开发者不是质量的变量，这要求不只是低代码（Low Code），而是零代码（Zero Code）；
意识，人们常说要有某种意识，对于架构而言，要加怎样的定语呢？建议：业务、客户、服务、体验、效率、成本、风险。架构工作的起点是业务的现状（baseline），然后要扩展到业务发展目标（target）、系统现状、团队现状，再到系统目标、整个信息化数字化的目标，这样才可能有清晰的架构发展路线图与里程碑，而这些意识要贯彻到整个过程中。
数据库如何建模 笔者从98年进入数据库及数据仓库领域工作至今已经有近八年的时间，对数据建模工作接触的比较多，创新性不敢谈，本文只是将工作中的经验总结出来，供大家一同探讨和指正。 提起数据建模来，有一点是首先要强调的，数据建模师和DBA有着较大的不同，对数据建模师来说，对业务的深刻理解是第一位的，不同的建模方法和技巧是为业务需求来服务的。而本文则暂时抛开业务不谈，主要关注于建模方法和技巧的经验总结。 从目前的数据库及数据仓库建模方法来说，主要分为四类。 第一类是大家最为熟悉的关系数据库的三范式建模，通常我们将三范式建模方法用于建立各种操作型数据库系统。 第二类是Inmon提倡的三范式数据仓库建模，它和操作型数据库系统的三范式建模在侧重点上有些不同。Inmon的数据仓库建模方法分为三层，第一层是实体关系层，也即企业的业务数据模型层，在这一层上和企业的操作型数据库系统建模方法是相同的;第二层是数据项集层，在这一层的建模方法根据数据的产生频率及访问频率等因素与企业的操作型数据库系统的建模方法产生了不同;第三层物理层是第二层的具体实现。 第三类是Kimball提倡的数据仓库的维度建模，我们一般也称之为星型结构建模，有时也加入一些雪花模型在里面。维度建模是一种面向用户需求的、容易理解的、访问效率高的建模方法，也是笔者比较喜欢的一种建模方式。 第四类是更为灵活的一种建模方式，通常用于后台的数据准备区，建模的方式不拘一格，以能满足需要为目的，建好的表不对用户提供接口，多为临时表。
下面简单谈谈第四类建模方法的一些的经验。 数据准备区有一个最大的特点，就是不会直接面对用户，所以对数据准备区中的表进行操作的人只有ETL工程师。ETL工程师可以自己来决定表中数据的范围和数据的生命周期。下面举两个例子： 1)数据范围小的临时表 当需要整合或清洗的数据量过大时，我们可以建立同样结构的临时表，在临时表中只保留我们需要处理的部分数据。这样，不论是更新还是对表中某些项的计算都会效率提高很多。处理好的数据发送入准备加载到数据仓库中的表中，最后一次性加载入数据仓库。 2)带有冗余字段的临时表 由于数据准备区中的表只有自己使用，所以建立冗余字段可以起到很好的作用而不用承担风险。 举例来说，笔者在项目中曾遇到这样的需求，客户表{客户ID，客户净扣值}，债项表{债项ID，客户ID，债项余额，债项净扣值}，即客户和债项是一对多的关系。其中，客户净扣值和债项余额已知，需要计算债项净扣值。计算的规则是按债项余额的比例分配客户的净扣值。这时，我们可以给两个表增加几个冗余字段，如客户表{客户ID，客户净扣值，客户余额}，债项表{债项ID，客户ID，债项余额，债项净扣值，客户余额，客户净扣值}。这样通过三条SQL就可以直接完成整个计算过程。将债项余额汇总到客户余额，将客户余额和客户净扣值冗余到债项表中，在债项表中通过(债项余额×客户净扣值/客户余额)公式即可直接计算处债项净扣值。
初学期货心得体会总结 通过初学期货总结，用一些简单的技术分析已经足以应付市场的很多状况了，正如当初感觉这么被万人传诵的“道氏理论”为啥仅仅三条一样的心得体会总结。下面是学习啦小编为大家收集整理的初学期货心得体会总结，欢迎大家阅读。 初学期货心得体会总结篇1 期货投资是这学期我接触的一门很新奇的科目：作为一个学管理的学生，对于会计、投资、股票、风险、期货等一系列的经济名词自然不陌生，但是实战或是具体操作从来也没尝试过。期货实验进行了短短4周的时间，我个人觉得学会了一点儿东西，不仅仅是关于如何进行期货交易，还包括个人对生活态度的剖析。 第一节课，老师为了培养大家对期货投资的兴趣，要大家做游戏，随着价格波浪的起伏，我们可以选择买卖，而且还要记录盈亏，大家做的都很认真。最后我核算了结果，发现自己赚了3000多块钱，心里感觉还是挺美的，也对这个实验有了期盼。紧接着我们开始了真正的期货投资：老师给每个同学的账户里存50万，可以利用它进行买卖。老师让我们先进行农产品买卖，引文价格波动小，风险相对要低。我买的是连玉米1106、沪铜1106和大豆，但是手数都很少，误打误撞在下课平仓之前赚了1万多。最开始下单后，始终眼睛紧盯着持仓明细的界面，时不时的刷新，
看着各项交易盈亏的起落，心都悬着，也有些明白了电视剧中股票投资者的心理。赚了高兴，亏了心急，大家第一次操作都很兴奋，教室里净是些“哎，涨了，涨了，赶紧平仓啊!”，“完了，跌了，我刚买的!”。周围有同学开玩笑说：“幸亏不是自己的钱，这要是心脏不好，可千万不能玩这个!”总之，第一节课，非常的尽兴。 一、“短线与长线的比较” 课后，我大概了解了一些期货交易具体时间，抽课余时间时不时进行一些交易。由于前一次买的铜和玉米成功了，我继续做这两种期货的交易。开始脑袋总是转不明白——一直是先买，看到价位合适就卖出，也许这就是初入行的通病。和很多同学一样，在期货投资中我喜欢天天到实验软件里看看，同时看见有的期货种类赔了喜欢留仓，盘算着“放长线钓大鱼”——例如沪铜1106，我买入了20手，在开始买进经历了一次小小的价格上涨后一直在跌，看着亏了13万，我想总会涨上来的，但最后跌了2000多，还同时持有其他种类的期货，占用的保证金太多，我被平仓了。开始以为是系统出了问题，后来很多同学都出了这个问题，经过交流才明白，我的账户也由54万变成了38万。 看着那个空荡荡界面有种说不出的感觉——这也就是成也萧何败也萧何!我不仅没钓到大鱼，连鱼竿也折了。因此，我认为，现在我们毕竟对期货认识还不够深刻，做“长
数学建模常用软件有哪些哈 MatlabMathematicalingoSAS详细介绍：数学建模软件介绍一般来说学习数学建模，常用的软件有四种，分别是：matlab、lingo、Mathematica和SAS下面简单介绍一下这四种。 1.MA TLAB的概况MA TLAB是矩阵实验室（Matrix Laboratory）之意。除具备卓越的数值计算能力外，它还提供了专业水平的符号计算，文字处理，可视化建模仿真和实时控制等功能。MATLAB的基本数据单位是矩阵，它的指令表达式与数学,工程中常用的形式十分相似,故用MATLAB来解算问题要比用C,FORTRAN等语言完相同的事情简捷得多. 当前流行的MA TLAB 5.3/Simulink 3.0包括拥有数百个内部函数的主包和三十几种工具包(Toolbox).工具包又可以分为功能性工具包和学科工具包.功能工具包用来扩充MATLAB的符号计算,可视化建模仿真,文字处理及实时控制等功能.学科工具包是专业性比较强的工具包,控制工具包,信号处理工具包,通信工具包等都属于此类. 开放性使MATLAB广受用户欢迎.除内部函数外,所有MA TLAB主包文件和各种工具包都是可读可修改的文件,用户通过对源程序的修改或加入自己编写程序构造新的专用工具包. 2.Mathematica的概况Wolfram Research 是高科技计算机运算( Technical computing )的先趋，由复杂理论的发明者Stephen Wolfram 成立于1987年，在1988年推出高科技计算机运算软件Mathematica，是一个足以媲美诺贝尔奖的天才产品。Mathematica 是一套整合数字以及符号运算的数学工具软件，提供了全球超过百万的研究人员，工程师，物理学家，分析师以及其它技术专业人员容易使用的顶级科学运算环境。目前已在学术界、电机、机械、化学、土木、信息工程、财务金融、医学、物理、统计、教育出版、OEM 等领域广泛使用。Mathematica 的特色·具有高阶的演算方法和丰富的数学函数库和庞大的数学知识库，让Mathematica 5 在线性代数方面的数值运算，例如特征向量、反矩阵等，皆比Matlab R13做得更快更好，提供业界最精确的数值运算结果。·Mathematica不但可以做数值计算，还提供最优秀的可设计的符号运算。·丰富的数学函数库，可以快速的解答微积分、线性代数、微分方程、复变函数、数值分析、机率统计等等问题。·Mathematica可以绘制各专业领域专业函数图形，提供丰富的图形表示方法，结果呈现可视化。·Mathematica可编排专业的科学论文期刊，让运算与排版在同一环境下完成，提供高品质可编辑的排版公式与表格，屏幕与打印的自动最佳化排版，组织由初始概念到最后报告的计划，并且对txt、html、pdf 等格式的输出提供了最好的兼容性。·可与C、C++ 、Fortran、Perl、Visual Basic、以及Java 结合，提供强大高级语言接口功能，使得程序开发更方便。·Mathematica本身就是一个方便学习的程序语言。Mathematica提供互动且丰富的帮助功能，让使用者现学现卖。强大的功能，简单的操作，非常容易学习特点，可以最有效的缩短研发时间。 3.lingo的概况LINGO则用于求解非线性规划（NLP—NON—LINEAR PROGRAMMING）和二次规则（QP—QUARATIC PROGRAMING）其中LINGO 6.0学生版最多可版最多达300个变量和150个约束的规则问题，其标准版的求解能力亦再10^4量级以上。虽然LINDO和LINGO不能直接求解目标规划问题,但用序贯式算法可分解成一个个LINDO和LINGO能解决的规划问题。模型建立语言和求解引擎的整合LINGO是使建立和求解线性、非线性和整数最佳化模型更快更简单更有效率的综合工具。LINGO提供强大的语言和快速的求解引擎来阐述和求解最佳化模型。■简单的模型表示LINGO可以将线性、非线性和整数问题迅速得予以公式表示，并且容易阅读、了解和修改。■方便的数据输入和输出选择LINGO建立的模型可以直接从数据库或工作表获取资料。同样地，LINGO可以将求解结果直接输出到数据库或工作表。■强大的求解引擎LINGO内建的求解引擎有线性、非线性(convex and nonconvex)、二次、二次
sql server实训总结4篇 sql server实训总结4篇 sql server实训总结篇一： 为期一周的实训已经结束，从这一周中，有了很多的感悟。从学到和掌握到的东西来说，在书本上学到的东西非常不牢固，然而实训真的让我受益匪浅! 实训第一天到教室时，看到老师给我们讲试训的内容与要求，然后告诉我们一些要完成的任务与作业，然后根据试训的内容与要求授课，让我们从实践中去体会所学的知识。说实话，对于SQL Server 数据库，我所学到的知识很不牢固，当时在课堂上听课所记住的也并不多，所以在试训开始时，真的不知道该干些什么?有一种何去何从的感觉!但随着老师的教课和讲解，以及和同学的讨论，再结合自己所知道的知识和老师所发放下的课程内容，根据这些实际的情况，我对自己将要做的事也有了兴趣和信心。所以在接下来的时间中，我们在老师的帮助下开始了数据库相关的实训。 在这次的google订餐系统的设计过程中，我们根据该google订餐系统的功能，将其分解三大部分来完成，第一部分就是建立数据库和表，并给其添加约束;第二是角色的管理，分为管理员，订餐用户和餐馆;第三就是用编程语言建立管理菜单。所以试训的内容是从数据库和数据表的创建和修改开始的，表是建立关系数据库的基本结构，用来存储数据具有已定义的属性，在表的操作过程中，有查看表属性，有查看表信息，修改表中数据，删除表中的数据以及修改表与删除表的操作。
我们以SQL Server数据库为基础，建立一个google订餐系统的数据库管理体系，并将数据库与程序连接，用编程语言建立数据库管理菜单。老师给我们讲了库和表的创建方法，以及约束的内心及其语法结构，让我们知道了不同约束的功能和使用的环境，还给我们说了标识列的使用和作用。讲了数据库的操作，增删改查。使我们掌握了insert into，deleted from，update set，以及selet*from语句的的相关知识和运用。其中还学到了分页查询以及多表查询。 从这次试训中让我们更明白了一些知识，表是数据库最重要的一个数据对象，表的创建好坏直接关系到数据库的成败，表的内容是越具体越好，但是也不能太繁琐，以后在实际运用中使用多表，对表的规划和理解就会越深刻。通过这次试训，让我深刻的了解到自己的不足，要想对进行数据库更深的学习，自己得要多看有关的课外书籍，并多做练习，不懂得要多问同学和请教老师，以解决自己遇到的难题，知道更多的知识。实训不仅是让我们在实践中对理论知识的验证，也让我们知道我们多学的知识在社会上的运用，把所学知识和企业商业接轨。 这次实训，不仅让我们学到了许多有关数据库的知识，老师也给我们讲了很多社会现状和就业情况，让我们不同的角度了解这个专业的就业趋势。让我们在今后的学习中更有动力的充实自己，曾加自己的知识面和锻炼自己各方面能力。 sql server实训总结 篇二：
数据库课程设计心得体会精选篇 课程培训活动，四对于提高专业技能的一个很好的方式，下面由小编为大家带来的数据库课程设计心得体会精选范文，仅供参考~ 数据库课程设计心得体会一 两个星期的时间非常快就过去了，这两个星期不敢说自己有多大的进步，获得了多少知识，但起码是了解了项目开发的部分过程。虽说上过数据库上过管理信息系统等相关的课程，但是没有亲身经历过相关的设计工作细节。这次实习证实提供了一个很好的机会。 通过这次课程设计发现这其中需要的很多知识我们没有接触过，去图书馆查资料的时候发现我们前边所学到的仅仅是皮毛，还有很多需要我们掌握的东西我们根本不知道。同时也发现有很多已经学过的东西我们没有理解到位，不能灵活运用于实际，不能很好的用来解决问题，这就需要我们不断的大量的实践，通过不断的自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用的东西。 从各种文档的阅读到开始的需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统的设计开发过程。很多东西书上写的很清楚，貌似看着也很简单，
思路非常清晰。但真正需要自己想办法去设计一个系统的时候才发现其中的难度。经常做到后面突然就发现自己一开始的设计有问题，然后又回去翻工，在各种反复中不断完善自己的想法。 我想有这样的问题不止我一个，事后想想是一开始着手做的时候下手过于轻快，或者说是根本不了解自己要做的这个系统是给谁用的。因为没有事先做过仔细的用户调查，不知道整个业务的流程，也不知道用户需要什么功能就忙着开发，这是作为设计开发人员需要特别警惕避免的，不然会给后来的工作带来很大的麻烦，甚至可能会需要全盘推倒重来。所以以后的课程设计要特别注意这一块的设计。 按照要求，我们做的是机票预订系统。说实话，我对这个是一无所知的，没有订过机票，也不知道航空公司是怎么一个流程。盲目开始设计的下场我已经尝过了，结果就是出来一个四不像的设计方案，没有什么实际用处。没有前期的调查，仅从指导书上那几条要求着手是不够的。 在需求分析过程中，我们通过上网查资料，去图书馆查阅相关资料，结合我们的生活经验，根据可行性研究的结果和客户的要求，分析现有情况及问题，采用client/server结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。在两周的时间里，不断地对程序及各模块进行修改、编译、调试、运行，其间遇到很多问题：由于忘记了一
期货投资分析的考试经验和心得 首先说明，我考的是期货投资分析，不是期货基础的那两科。还是先把分报上，刚查的新鲜出炉，62分，擦边过，看似有点侥幸，然则就前辈经验而看，除通过率较高的第一次考试外通过的成绩基本上为60-70，所以也算正常。这次考试参考人员是7168人，及格人数是274人，通过率为3.82%。我这是第一次考，之前也因为不熟悉考试模式、内容和难度，望着那低迷的通过率而抓耳挠腮，正是这些困惑使得我坚定了如果通过就写经验分享的决心，以帮助更多后来之士啃下这块硬骨头！ 我说它是硬骨头一点不足为过，它的难度不亚于CIIA（因为这个我也通过了，才敢这么说）。为了让大家更清晰的认识这个考试，我分别介绍这个考试的结构，内容和难度，考试技巧和几点建议。 （1）结构。考试分为单选，多选，判断和综合题，并以上述顺序依次出现，并不会出现网上的2011年5月真题中杂乱无章的形式（这个问题曾困扰我很长时间）。上述题型的题量和分值各为30，20，15和35，也即每题1分，共100题，以60分为通过。以单选为例，可以是一个题干一个问题，也可能是一个题干若干问题，但单选总题数为30，即30分。一个题干若干问题的出题方式在综合题中最为常见。综合题为不定项选择，即至少有一个正确答案。 （2）内容和难度。先说对考试内容的考察特点，内容是难度的根源，考试的大多数内容都来自于那本指定教材，但又脱离于该教材，考试内容中较少出现教材上原原本本的
内容，比如问你“期货价格的特殊性是什么：特定性，预期性，远期性，波动敏感性。”只需记住就可作答，这种类型的题在期货投资分析考试中基本不会出现。考察的方式是通过对知识的理解和融会贯通的基础上作答，光记住套期保值交易策略有哪几种是不够的，而要理解每种策略适用于何种环境，以及具体的操作方式是什么，才能较好的完成试题。再说内容的范围，这是令大多数人跌倒的门槛，首先将内容分为书内和书外，比例应该是7：3，书内的内容考察方式如前所述，在于理解和掌握。书外的内容主要是包括当年所发生的经济时事和杂类，经济时事考察类型分为两种，一是纯粹看你是否对全球经济中的热点 问题是否了解，比如问你“美联储QE3的操作方式是什么？”，“欧洲央行为缓解欧债危机出台的货币策略（此题为不定项，4个选项还都是英文）”；二是结合书中内容尤其是套保，套利，投机策略，还包括期权的组合策略运用，解决实际问题。杂类则相对更不好把握，如考察“甘蔗的榨糖季是几月到几月”，“观察原油期货价格波动性主要是参照哪三种原油价格的加权平均价格”，即使是期货从业人员也只是对自己所研究的几个期货品种有所了解，而不可能对所有品种面面俱到，更何况类似于我这样的学生，这无疑也是增加了很大的难度。此外，还涉及诸如CAPM等财务方面的相关知识，这要求考生对经济金融领域有个比较全面的了解。 （3）考试技巧。在时间问题上，考试时间为100分钟，万不可以为只要保证1题1分钟即可。我前面说的该考试比CIIA难，难就难在时间上，尤其是综合题上，一个很复杂的题干也许就2个小问题，极为费时费力。在时间具体安排上，考虑单选和判断较容易，需要快速作答，但是也强调这是拿分的要点题型，一定要建立在熟练掌握教材知识的基础
数学建模个人经验谈 在数学建模中文献资料的查找是十分关键，其实不仅是在数学建模中，在学习和做研究就是如此，不阅读文献资料就相当于闭门造车，什么都弄不出来，现在的工作几乎都可以说是站在前人的肩膀上，从出生开始就是站在前人的肩膀上了，所学的任何书本知识都是前人总结出来的。 通过文献资料的阅读可以知道别人在这个方面做了多少工作了，怎么做的工作，取得了哪些进展，还存在什么问题没解决，难点在哪里，热点在哪里，哪里是关键，哪些是有价值的，哪些是无意义的等等等等......，并且可以通过查找文献得到一些很有用的信息，比如某个教授牛的程度，所擅长的领域等等，呵呵，翻教授老底了，比较好玩，选导师的时候强烈推荐。 文献查找主要有三个模式： A. 书 B. 书+中外文期刊数据库 C. 书+中外文期刊数据库+学位论文 D. 书+中外文期刊数据库+学位论文+搜索引擎 对于全国赛推荐D模式，但要改为Dc模式：中外文期刊数据库+学位论文 对于美赛则要改为Da模式：外文期刊数据库+搜索引擎 在此要解释下为何如此推荐，对于参加建模的来说一般书基本上是用不上了的，没必要去查了，直接查找数据库即可了，全国赛的题目大多是研究了很多年的东西了，这个也是和国内学术环境相关的，虽然近几年的赛题是体现最新形式的，但是相关的研究还是有的，还是可以参考的，要知道国内鲜有几个教授牛的站在国际前沿还给本科生出个数模题玩玩的，一般都是老东西新面孔的。也就是可以归类为学术研究类的新面孔老方法类。所以查数据库是最有效率的方法，并且查学位论文是尤其推荐的，要知道查找学位论文是最高效率得到信息的途径。虽然学位
论文很长，很吓人，没有七八十页也有个一百多页，其实看多了学位论文就知道真正有用的东西页就那么个十多页最多二十多页，直接翻到那个部分看就可以了，为什么篇幅这么大就和中国的教育中的一些硬性指标相关了，每个级别的学位论文都有一个规定的字数范围，虽然大部分是垃圾，但为了达到这个字数要求也得凑足这个数字，水了，中国高等教育的悲哀啊。 美赛则有语言障碍，要在有限时间内完成课题研究和论文写作，则需直接查找外文文献了，要知道中国目前的总体科学水平和国外的差距是至少5年的，这个是保守估计，实际可能是2倍以上。所以一般国外的当前研究国内鲜有涉及，当国外搞的很成熟了，产业化了，咱们国内就有教授引进了，开始研究了，吃点人家的残羹冷炙，这样说是刻薄了点，但这种情况真的不少见。这个就是中文数据库在美赛中无用的原因了。此外在美赛中用搜索引擎的实际效果好的往往出人意料，基本可以这么说，用搜索引擎比数据库来的更好，介绍一个n多人知道的技巧，怕还有人不知道就在此罗嗦下：搜索引擎用google足以，点击高级搜索，然后输入需要的 key words，在格式中选pdf格式。很简单吧，但很实用，填句弱智的话，报选择中文搜索啊，碰到过一次朋友如此搜索的，当时巨汗！很多参加数模的同学对 pdf格式了解很少，实在不应该吧，在下估计这帮人都是学习成绩好的不得了的，没怎么用过计算机和没怎么上网，并且是word的忠实铁杆用户。pdf格式就是一种国外通用的标准便携电子文档格式，要知道外国人几乎不用ms word的，微软发财中国人民的贡献巨大啊（虽然盗版盛行）。 顺便介绍下国内外主要数据库的文献格式：pdg是超星格式，caj和caa为清华同方数据库（cnki）（它有三个名头，中国学术期刊网什么什么的NB名字也是指它），vip为维普，最重头的就是pdf，都需要不同的阅读器才能打开，还好都是免费的。
19年期货作手经验总结 一?投资前提 1.自己生活有保障 2.家庭生活有保障 3.不用紧急的钱投资 4.不借钱投资 5.不用信用卡的钱投资6?用闲钱投资，并且要留一定的现金以备急用? 二投资方式 1）专职投资1?时间多，要业务精. 2?要资金多 3.可适当多投资高风险高回报的品种. 4.要分散投资（股票，期货，基金，黄金，权证，外汇，保险，房地产，收藏，定期活期存款等） 2）兼职投资 1.时间少，业务一般. 2.资金可多可少3?投资风险低品种，长期投资. 4.分散投资（股票，期货，基金，黄金，权证，外汇，保险，房地产,收藏, 定期活期存款等） 3）最好不要合伙投资。 期货投资W大误区 1?满仓交易-满仓必输
2.频繁交易-缺乏技术指导 3.逆势操作-小概率大风险 4.锁仓交易-不接受亏损事实 5.拉低拉高持仓均价-错上加错 6.测顶测底,不设止损-给错误寻找理由 7.多完就空,空完就多-过于追求完美是无目标 8.听信消息,盲目跟风-缺乏对市场了解 9.不善自省,怀疑市场-对行情产生恐惧 10.制定长期交易计划-未来是不可控的 新手重大亏损原因 1.重仓死亡，从1万到10万要几百次，从10万到0只需1次. 2.幻想逆市反扛死亡，不要与中长期趋势对抗. 3.频繁交易砍仓死亡,心随市场波动很快将被钓岀市场. 4.拖时间等于慢性自杀? 5?死的都是太贪的 期货市场八对八错 1.以顺势操作为对，以逆市为错（趋势一但形成，很难短时改变） 2.以轻仓为对，以重仓为错-仓位影响态度，态度影响分板决策 3.以知足为对，以贪焚为错-贪焚是敌人，知足常乐是要决4?以止损保盈为对，以放任自流为错-保木第一，赚钱第二 5.以客观操作为对，以主观分析为错客观操作，遵守规则 6.以等待忍耐为对，以浮躁冲动为错，培养耐心，合适时机才行动 7.以盈利加码为对，以被套加仓为错，盈利是正确方向,被套是错误方
数据库实验心得 没接触数据库的时候总是觉得它比较深奥或是不可接近的电脑知识，尽管自己对电脑非常感兴趣，其实还是有些心理上的陌生感。学习电脑就和我们平时的其它科目学习一样感觉它有永无止境的知识，在这从初接触电脑时连个电脑的键盘都不敢动到现在连硬盘都也修理，其中的过程是多么长啊，数据库是我在高中时候听过，到了大学渐渐了解了些，但就其原理性的内容还不知道，也就是根本就不清楚什么是数据库，只是知道一个所谓的中国字典里的名词。经过此次的课程设计，我初步明白了数据库的基本原理。也已经掌握了数据库的基本知识。我想对我以后的更深度学习打下了基础。这次课程设计让我知道了让 vb 连接 sql 的方法。其实就是前台和后台的连接。有了这个思想，我相信对以后是大有裨益的。 我按照系统工程软件设计的要求，从需求分析，概念设计，总体设计，详细设计，系统测试等各个步骤，分步完成系统的各项任务，实现了系统中的学生信息查询，学生信息更新，学生信息添加等模块的功能。在这短短的五天里我收获如下： 1、巩固和加深了对 c#的理解，提高综合运用本课程所学知识的能力。 2、培养了我选用参考书，查阅手册及文献资料的能力。培养独立思考，深入研究，分析问题、解决问题的能力。 3、通过实际编译系统的分析设计、编程调试，掌握应用软件的分析方法和工程设计方法。根据我在课程设计中遇到的问题，我将在以后的学习当中注意以下几点： 1、认真上好专业实验课，多在实践中锻炼自己。 2、写程序的过程中要考虑周到，严密。 3、在做设计的时候要有信心，有耐心，切勿浮躁。 4、
认真的学习课本知识，掌握课本中的知识点，并在此基础上学会灵活 运用。 5、在课余时间里多写程序，熟练掌握在调试程序的过程中所遇到的常见错误，以便能节省调试程序的时间 第二篇：数据库实验心得 我在sql server 索引基础知识系列中,第一篇就讲了记录数据的基本格式。那里主要讲解的是，数据库的最小读存单元：数据页。一 个数据页是8k大小。 对于数据库来说，它不会每次有一个数据页变化后，就存到硬盘。而是变化达到一定数量级后才会作这个操作。这时候，数据库并不是以数据页来作为操作单元，而是以64k的数据（8个数据页，一个区）作为操作单元。 区是管理空间的基本单位。一个区是八个物理上连续的页（即 64 kb）。这意味着 sql server 数据库中每 mb 有 16 个区。 为了使空间分配更有效，sql server 不会将所有区分配给包含少量数据的表。sql server 有两种类型的区： 统一区，由单个对象所有。区中的所有 8 页只能由所属对象使用。 混合区，最多可由八个对象共享。区中八页的每页可由不同的对象所有。 通常从混合区向新表或索引分配页。当表或索引增长到 8 页时，将变成使用统一区进行后续分配。如果对现有表创建索引，并且该表 包含的行足以在索引中生成 8 页，则对该索引的所有分配都使用统一区进行。 为何会这样呢？
二十年期货人的心血经验精华 一、投资前提 １．自己生活有保障 ２．家庭生活有保障 ３．不用紧急的钱投资 ４．不借钱投资 ５．不用信用卡的钱投资 ６．用闲钱投资，并且要留一定的现金以备急用。 二、投资方式：专职投资 １．时间多，要业务精。 ２．要资金多。 ３．可适当多投资高风险高回报的品种。 ４．要分散投资（股票，期货，基金，黄金，权证，外汇，保险，房地产，收藏，定期活期存款等） 三、投资方式：兼职投资 １．时间少，业务一般。 ２．资金可多可少。 ３．投资风险低品种，长期投资。 ４．分散投资（股票，期货，基金，黄金，权证，外
汇，保险，房地产，收藏，定期活期存款等） 5．最好不要合伙投资。 四、期货投资１０大误区 １．满仓交易－满仓必输 ２．频繁交易－缺乏技术指导 ３．逆势操作－小概率大风险 ４．锁仓交易－不接受亏损事实 ５．拉低拉高持仓均价－错上加错 ６．测顶测底，不设止损－给错误寻找理由 ７．多完就空，空完就多－过于追求完美是无目标 ８．听信消息，盲目跟风－缺乏对市场了解 ９．不善自省，怀疑市场－对行情产生恐惧 10.制定长期交易计划－未来是不可控的 五、新手重大亏损原因 １.重仓死亡，从１万到10万要几百次，从10万到0只需１次。 ２.幻想逆市反扛死亡，不要与中长期趋势对抗。 ３.频繁交易砍仓死亡，心随市场波动很快将被钓出市场。 ４.拖时间等于慢性自杀。
５.死的都是太贪的。 六、期货成功的理念 １．顺势而为，流水不争 ２．大处着眼，小处着手 ３．忘记成本，坦然进出 ４．不急不燥，心无盈亏 ５．风险第一，量力而为 ６．心平气和，财富自集 七、期货市场的八对八错 １.以顺势操作为对，以逆市为错——趋势一但形成，很难短时改变。 ２.以轻仓为对，以重仓为错——仓位影响态度，态度影响决策。 ３.以知足为对，以贪婪为错——贪婪是敌人，知足常乐是要决。 ４.以止损保盈为对，以放任自流为错——保本第一，赚钱第二。 ５.以客观操作为对，以主观分析为错——客观操作，遵守规则。 ６.以等待忍耐为对，以浮躁冲动为错——培养耐心，
数据库概念设计及数据建模(一) 一、选择题 1. 数据库概念设计需要对一个企业或组织的应用所涉及的数据进行分析和组织。现有下列设计内容 Ⅰ．分析数据，确定实体集 Ⅰ．分析数据，确定实体集之间的联系 Ⅰ．分析数据，确定每个实体集的存储方式 Ⅰ．分析数据，确定实体集之间联系的基数 Ⅰ．分析数据，确定每个实体集的数据量 Ⅰ．分析数据，确定每个实体集包含的属性 以上内容不属于数据库概念设计的是______。 A.仅Ⅰ、Ⅰ和Ⅰ B.仅Ⅰ和Ⅰ C.仅Ⅰ、Ⅰ和Ⅰ D.仅Ⅰ和Ⅰ 答案：D [解答] 数据库概念设计主要是理解和获取引用领域中的数据需求，分析，抽取，描述和表示清楚目标系统需要储存和管理什么数据，这些数据共有什么样的属性特征以及组成格式，数据之间存在什么样的依赖关系，同时也要说明数据的完整性与安全性。而数据的储存方式和数据量不是概念设计阶段所考虑的。 2. 关于数据库概念设计阶段的工作目标，下列说法错误的是______。 A.定义和描述应用系统设计的信息结构和范围
B.定义和描述应用系统中数据的属性特征和数据之间的联系 C.描述应用系统的数据需求 D.描述需要存储的记录及其数量 答案：D [解答] 数据库概念设计阶段的工作目标包括定义和描述应用领域涉及的数据范围；获取应用领域或问题域的信息模型；描述清楚数据的属性特征；描述清楚数据之间的关系；定义和描述数据的约束；说明数据的安全性要求；支持用户的各种数据处理需求；保证信息模型方便地转换成数据库的逻辑结构(数据库模式)，同时也便于用户理解。 3. 需求分析阶段的文档不包括______。 A.需求说明书 B.功能模型 C.各类报表 D.可行性分析报告 答案：D [解答] 数据库概念设计的依据是需求分析阶段的文档；包括需求说明书、功能模型(数据流程图或IDEF0图)以及在需求分析阶段收集到的应用领域或问题域中的各类报表等，因此本题答案为D。 4. 数据库概念设计的依据不包括______。
目标: 本文主要介绍PowerDesigner中概念数据模型 CDM的基本概念。 一、概念数据模型概述 数据模型是现实世界中数据特征的抽象。数据模型应该满足三个方面的要求： 1）能够比较真实地模拟现实世界 2）容易为人所理解 3）便于计算机实现 概念数据模型也称信息模型，它以实体－联系(Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库的概念级设计。 通常人们先将现实世界抽象为概念世界，然后再将概念世界转为机器世界。换句话说，就是先将现实世界中的客观对象抽象为实体(Entity)和联系(Relationship),它并不依赖于具体的计算机系统或某个DBMS系统，这种模型就是我们所说的CDM;然后再将CDM转换为计算机上某个DBMS所支持的数据模型，这样的模型就是物理数据模型,即PDM。 CDM是一组严格定义的模型元素的集合，这些模型元素精确地描述了系统的静态特性、动态特性以及完整性约束条件等，其中包括了数据结构、数据操作和完整性约束三部分。 1）数据结构表达为实体和属性; 2）数据操作表达为实体中的记录的插入、删除、修改、查询等操作; 3）完整性约束表达为数据的自身完整性约束（如数据类型、检查、规则等）和数据间的参照完整性约束（如联系、继承联系等）;
二、实体、属性及标识符的定义 实体（Entity），也称为实例，对应现实世界中可区别于其他对象的“事件”或“事物”。例如，学校中的每个学生，医院中的每个手术。 每个实体都有用来描述实体特征的一组性质，称之为属性，一个实体由若干个属性来描述。如学生实体可由学号、姓名、性别、出生年月、所在系别、入学年份等属性组成。 实体集（Entity Set）是具体相同类型及相同性质实体的集合。例如学校所有学生的集合可定义为“学生”实体集，“学生”实体集中的每个实体均具有学号、姓名、性别、出生年月、所在系别、入学年份等性质。 实体类型（Entity Type）是实体集中每个实体所具有的共同性质的集合，例如“患者”实体类型为：患者｛门诊号，姓名，性别，年龄，身份证号.............｝。实体是实体类型的一个实例，在含义明确的情况下，实体、实体类型通常互换使用。 实体类型中的每个实体包含唯一标识它的一个或一组属性，这些属性称为实体类型的标识符（Identifier），如“学号”是学生实体类型的标识符，“姓名”、“出生日期”、“信址”共同组成“公民”实体类型的标识符。 有些实体类型可以有几组属性充当标识符，选定其中一组属性作为实体类型的主标识符，其他的作为次标识符。 三、实体、属性及标识符的表达
数据库实验心得体会 有关于数据库实验的心得体会，总的来说，受益匪浅。在这些天中，我们学到了很多东西，包括建表，导入数据，查询，插入。最重要的是我们有机会用电脑自己进行实践，没接触的时候总是觉得它比较深奥或是不可接近的新型语言，尽管自己对C语言非常感兴趣，但还是有些心理上的陌生感。学习数据库就和我们平时的其它科目学习一样感觉它有永无止境的知识，数据库是我在高中时候听过，到了大学渐渐了解了些，但就其原理性的内容还不知道，也就是根本就不清楚什么是数据库，只是知道一个所谓的中国字典里的名词。我认识它是从我接触实验运作开始的，刚开始就是建立数据库，两种验证模式，没什么东西但还觉得不错。进而就是操作语言了，紧接着就是触发器的使用，进而对数据库高级的使用，等等。 开始知道数据库的时候想学，不知道从何而起，不懂的话怎么问，从什么地方学起。后来到大三开学后有数据库原理必修课，非常高兴。当时感觉SQL Sever数据库管理既然是单独一门课程一定会讲的比较细，也能学到真正实用的内容。学了这门课以后发现和我想的基本是一样的，老师对学生也比较和蔼可亲，对我们要求也不是很紧。让每个人都觉得轻轻松松就能把这门课程学完，没有多么紧张的作业，也没有太苛刻的要求。 当老师在最后说这个课程结束了，回顾一下以前老师给我们讲过的东西，真的有很多是我们应该去注意的。学习完SQL Sever数据库后感觉可分两大块，一块是开发，一块是管理。开发主要是写写存储过程、触发器什么的，还有就是用Oracle的Develop工具做form。有点类似于程序员。开发还需要有较强的逻辑思维和创造能力，自己没有真正做过，但感觉应该会比较辛苦，是青春饭；管理则需要对SQL Sever数据库的原理有深刻的认识，有全局操纵的能力和紧密的思维，责任较大，因为一个小的失误就会弄掉整个数据库，相对前者来说，后者更看重经验。这些东西都是从老师哪里和朋友的讨论中得到的心得，也希望其他朋友能多多向老师和朋友请教，如果是个人单独靠自己来完成一个完美的数据库我觉得比较困难，现在基本上都是团队类型的，而且他们的效率高开发的周期也快。由于数据库管理的责任重大，很少公司愿意请一个刚刚接触SQL Sever的人去管理数据库。对于我们这些初出茅庐的新手而且电子商务的专业，个人认为可以先选择做管理，有一定经验后转型，去做数据库的开发。当然，这个还是要看人个的实际情况来定。 SQL Server数据库的实验学习使我对数据库的有了新的进步，以后再看到也就不至于什么也不懂，其实那么多数据库我觉得学好一门就行，只是他们的语言可能不大一样，学好一门后就可去认识其它的，这样应该有事半功倍的效果。就像我学习C语言，当时不能说是学习的棒，但不算差。所以我对以后的语言感觉都不是很困难，了解了VB、C++还有网页中用的Html语言、asp语言都能看懂，起码可以对别人的东西进行了一下修改。因此，我感谢数据库老师给了我有用的知识，以便我在以后学习或认识更多的内容能有新的方法和思维，也能更加有效和快速的去消化吸收新的东西。希望在今后中，SQL Server能给我更多帮助。感谢学校开设这样一门优秀使用的课程，让我对数据库有了更深的了解。
数据库建模技术实验报告 《数据库建模技术》实验报告 《数据库建模技术》实验报告 VCD租售连锁店管理系统 的数据库设计 班级: 114030602 学号: 11403060211 姓名: 杨盼 2016年6月 28日 第 1 页共 34 页 《数据库建模技术》实验报告 “数据库建模技术”实验需求文字 根据以下开发VCD出售租借连锁店管理系统需求调查文字，完成实验一至实验五。 市内某家大型VCD出售租借连锁店有许多员工，每个员工只能服务于一家租借店;每个员工有工号、姓名、性别、年龄、政治面貌等属性;每家店日常工作主要有:租借、归还、逾期罚款等,租借人首先要办理租借卡～租借卡分为年卡、月卡和零租卡,。具体操作流程如下: (1)出售租借:根据购买人或租借人提供的VCD租借单，查阅库存，如果有，则办理销售或租借并登记销售(记录销售记录单号、购买人卡号、购买日期、VCD编码、数量、单价～经办员工号)或租借流水帐(记录租借记录单号、租借人卡号、租借日期、VCD编码、数量、归还日期～经办员工号);如果没有相应的VCD ，则可根
据购买人或租借人的要求办理预约登记(记录预约登记单号、购买或租借卡卡号、VCD编码、数量、经办员工号)，当有VCD时，及时通知购买人或租借人。 (2)归还:根据租借人提供的所还VCD，检查VCD是否完好，如果完好，则办理归还登记(记录归还单号、租借人卡号、归还日期、VCD编码、数量、经办员工号)，如果有损坏的VCD，办理赔偿登记(记录赔偿单号、租借卡卡号、赔偿日期、赔偿VCD编码、数量、金额～经办员工号)，并把赔偿通知单通知给租借人。 (3)逾期罚款通知:查询逾期未还的VCD，及时通知租借人，并进行相应的罚款登记(记录罚款单号、租借卡卡号、罚款日期、罚款金额、经办员工号)。 第 2 页共 34 页 《数据库建模技术》实验报告 实验一需求分析(一)——业务流程调查 一、实验目的:掌握需求分析的步骤和业务流程调查的方法;掌握应用Powerbuilder绘制BPM模型 二、学时:6H(课内4H，课外2H) 三、实验软件平台:Windows 2k或Windows XP, Powerduilder9.5,Visio 四、实验内容:根据该VCD连锁店的业务需求调查文字，利用PD绘制该VCD连锁店管理系统的BPM模型。 五、实验结果: 【请在此粘贴你的BPM～地方不够可换页】 是否有卡办理卡 存入销售记录 存入租借记录生成租借单 记录销售借VCD选择店家 记录租赁租VCD判断租或借是否有库存
期货投资交易实习心得 一、总论 我在大学之前，对于“期货交易”这个词闻所未闻，更不用 说对期货交易原理的掌握和运用了。上大学之后，第一次学习接 触期货交易是在国际金融这门课上，那时潘权富老师着重讲了包 括“看跌期权”、“看涨期权”等期权的种类，但这只是一次非 常浅显的学习，真正系统的学习则是在这学期的期货与期权交易 课上，而且还安排有实验课。在实验课上，不仅学到了期货交易 的操作知识，还有交易过程中的体会和感想，以下将从交易情况、亏损原因、投资心得体会等方面对期货投资进行总结。 (一)交易情况 交易结果 由此可以看出，最后的交易结果为亏损。 (二)亏损原因分析 1.缺少对交易品种的深入分析，没有充分利用已有的信息; 2.不能很好地进行技术面分析，凭感觉盲目进行交易; 3.有投机心理，不能正确把握盈利和亏损的“度”; 4.偶然因素，有一节实验课，交易系统无法进行正常交易。 二、期货交易投资心得体会 在实验课上，既有亏也有赚，既感受到了期货交易中的乐趣，也体会到了期货市场的变幻莫测，以下是我的心得体会。
(一)把握好交易时间 开始上实验课时，老师向大家介绍了“世华财讯”软件的使 用方法和期货交易的规则方式等，然后大家进行实盘操作模拟交易。在操作过程中，我发现交易不了，而且其他一些同学也出现 这种情况，后来经过老师解释，大 家才明白原来是不到交易时间，下午13:30才能开始进行交易，此时距离开盘时间还差一点点，所以交易不了。通过这次实 验课我才知道国内期货交易所的交易时间：上交所9点至10点15，10点半至11点半，下午1点半至2点20，2点半至3点。大商所与郑商所：9点至10点15，10点半至11点半，下午1点半至3点。中金所：9点15至11点半，下午1点至3点15，最后交易日下午1点至3点。这些常识，对于我们这些初次进行期货交易的学生来说，恐怕大多数人都不清楚，甚至是不知道。 有了这次的经历，我想我们至少了解到了期货交易的起止时间，以后再同别人进行交流时不至于出笑话，而且还增加了自己 的常识。我们应该反思自己，尤其是将来要考公务员的，不断地 学习，不断地拓宽自己的知识面就显得尤为重要。 (二)真正做好技术面分析 在起初进行交易时，我只是凭感觉买卖期货：比如产品走势 处于下跌走势时，我就买入，因为我认为一定会上涨，只要上涨 我就会赚钱几笔交易下来，我发现赚的次数远远少于亏钱的次数。通过多次观察后，原来有的产品正处于下跌趋势，但是在以后的
《数据库原理》实验报告 一、实验目的： 1、使用Powderdesigner建模工具完成本实验。 2、完成下列表中所描述数据库的概念数据模型设计，对关键字、空值、域完整性等做出必要的描 述，根据实际情况确定联系的类型。 3、依据所涉及的概念数据模型（CDM）生成相应的物理数据模型(PDM)，可以对生成的物理数据模 型作必要的修改。 4、生成建立数据库的目标代码。 二、实验使用环境： SQL server 2012、Powerdesigne:16.5 三、实验内容与完成情况： 1.创建概念模型 客户与订购单是一对多的关系：一个客户可以有多个订购单，但是一个订购单只能属于一个客户订购单与产品是多对多的关系：一个产品可以有多个订购单，一个订购单也可以包括多个产品内容 2.属性数据类型 客户表：
产品表： 订购单表： 3.概念模型转换为物理模型 由于客户与订购单是一对多的关系，所以客户的主键（客户号）存在于订购单中做外键，加入订单日期由于订购单与产品是多对多的关系，所以订购单的主键（订单号）和产品的主键（产品号）存在于两者的关系订单明细中作为主键和外键，另外加入序号和数量作为
4.约束条件 客户号：前两个字符为字母 客户名称：不允许为空值： 邮政编码：6位数字字符 电话：数字字符 电子邮箱：包含@字符
产品号：前两个字符为字母 产品名称：值唯一 单价：>0 客户号：不允许空值
订购日期：默认是系统时间 序号：自增1，初值1 5.生成数据库脚本 得到商店.sql 脚本，见附件 新建数据库
测试结果： 连接数据源 导入数据库：