策划案标准与规范.docx

1、 策划案标准与规范策划案标准与规范 策划案规范与标准 一、策划案的结构规范性（一）策划案的格式与内容 1、采集表策划案内容：一、简明描述 1、简介：说明表存储的数据内容、主要用途、使用说明等。2、来源：说明表的数据来源,如从某网站采集、通过哪些表计算出来的等 3、维护时间及频率：说明表的数据更新频率及时间，如每日几点自动触发更新，人工每天几点采集入库 4、重要字段及数据情况：说明本表的一些重要字段，这些重要字段及所有字段的数据维护情况，数据质量，历史数据情况。二、表结构（技术文档）（见策划案的规范及标准）2、产品表策划案内容：（通用）一、简明描述 1、简介：说明表存储的数据内容、主要用途、使用

2、说明等。2、来源：说明表的数据来源,如从某网站采集、通过哪些表计算出来的等 3、维护时间及频率：说明表的数据更新频率及时间，如每日几点自动触发更新，人工每天几点采集入库 4、重要字段及数据情况：说明本表的一些重要字段，这些重要字段及所有字段的数据维护情况，数据质量，历史数据情况。二、表结构（技术文档）（见策划案的规范及标准）（二）策划案的规范及标准 新的表结构主要是配合新的字典工具而设置，如果新建表需要利用新的字典工具，则一定要按照新的表结构策划表，目前可以利用新工具建表的库有 CGENIUS 和PGENIUS。标准的表结构：（新）基金综合信息表(FND_GEN_INFO)序号 中文名 英文名

3、 类型 精度 空值 缺省值 量纲 备注 入库方式 1基金标识 FUND_ID int YES 转型基金、分级基金、保本基金等基金标识相同 采集 2基金内部代码 INNER_CODE int NO 赋予内部使用的代码，转型前后相同 采集 3变动日期 CHANGEDATE datetime NO 基金发生变动的公告日期 采集 4变动原因 CHNG_REASON int YES 变动原因（CHNG_REASON）与“综合参数表（GEN_REF)”表中的“参数代码(REF_CODE)”关联，“CLS_CODE=3006”，得到基金类型的具体描述:1-封转开；2-开转开；3-基金分级；4-基金复制；5-

4、保本基金关联；6-新基金成立；7-基金管理人变更；8-封闭期结束；采集 9-基金名称变更；10-同级基金关联 5基本信息 LABEL0101 采集 6基金代码 FUND_CODE varchar 12 NO 基金实际交易代码 采集 7ISIN编码 ISIN VARCHAR 12 YES 采集 8深市行情代码 SZSE_CODE varchar 12 YES 对于封闭式基金，行情代码基金代码 采集 9沪市行情代码 SHSE_CODE varchar 12 YES 对于封闭式基金，行情代码基金代码 采集 10 前端申购代码 APPL_BUY_CODE_FRONT varchar 12 YES 采集

5、 11 后端申购代码 APPL_BUY_CODE_BACK varchar 12 YES 采集 12 基金简称 FUNDSNAME varchar 30 YES 按巨灵简称编制规则编制 采集 13 拼音简称 CHI_ABBR varchar 20 YES 按巨灵简称编制规则编制 采集 14 基金简称二 FUNDSNAME_2 varchar 20 YES 据交易所公布的简称编制 采集 15 拼音简称二 CHI_SPELL_2 varchar 20 YES 据交易所公布的简称编制 采集 16 英文简称 ENG_ABBR varchar 20 YES 采集 17 基金全称 FUNDNAME var

6、char 80 YES 采集 18 基金简介 FND_BRIEF text YES 采集 19 基金类型 FND_TYPE int YES 基金类型（FUND_TYPE）与“综合参数表（GEN_REF)”表中的“参数代码(REF_CODE)”关联，“CLS_CODE=3001”，得到基金类型的具体描述:0-其它；1-契约型封闭式；2-契约型开放式；3-ETF；4-LOFs；5-创新型封闭式；6-创新型开放式；采集 7-外币基金；8-FOF 20 基金类型描述/基金类型名称 FND_TYPE_NAME varchar 50 YES 采集 21 基金机构代码 ORG_CODE INT YES 关联

7、：采集 22 基金机构代码处理标识 ORG_CODE_MARK INT YES 关联 WHERE CLS_CODE=13 23 管理人代码 MANA_CODE int YES 关联：采集 24 管理人代码处理标识 MANA_CODE_MARK INT YES 关联：WHERE CLS_CODE=13 25 管理人名称 MANA_NAME varchar 200 YES 采集 26 货币型基金红利计提和分配方式 CURNCY_DISTIL_CLS int YES 红利计提方式（TRADE_MKT）与“综合参数表（GEN_REF)”表中的“参数代码采集 (REF_CODE)”关联，“CLS_COD

8、E=3002”，得到红利计提方式的具体描述:0-其它；1-按日；2-按月 27 相关日期 LABEL0102 采集 28 设立日期 ESTAB_DATE datetime YES 基金发生变动后的设立日期（如转型、分级、保本续期、封闭期结束等）采集 29 上市日期 LIST_DATE datetime YES 采集 30 基金到期日 FUND_MATU datetime YES 采集 31 存续期限 DURATION numeric 9,4 YES 年 采集 32 初始设立日期 INIT_ESTAB_DATE datetime YES 基金初始成立日期，可追溯到基金转型前、分级前的最早设立日期

9、 采集 主码特性:基金内部代码+变动日期 唯一索引：备注：货币型基金一般存在红利计提方式（按日按月）、收益分配方式（按日按月）、收益结转份额方式（按日按月）、收益支付方式（按日按月）四种说法，目前各基金公司在基金合同中并未给出明确、一致的表达方式。其中红利计提方式与收益支付方式一般都是一般都是按月计提分配。收益结转份额方式各不相同。收益支付方式一般为按月集中支付。本表记录了基金成立、转型、分级、保本期变更、管理人变更、基金名称变更等基金成立以来的变动情况。-二、技术文档的规范性（一）格式要点：1、为了策划案的统一规则性，整个技术文档必须用“宋体五号字”，所有内容中不允许有“超级链接”1、序号必

10、须完整，这是对以后数据字典的 WEB版而言的完整性的维护，但是不能采用特殊的文本格式，必须无文本格式 2、字段类型若为 INT和 DATETIME时，字段精度为空 3、在字段备注中不允许存在“段落标记”回车键，在表结构中都不允许存在的 4、主键采用“黄色”底纹标注，同时在主码特性中必须与标注的一样，同时存在几个主键时，字段名中间用+，如“公司代码+报表日期+项目代码”5、主键字段不允许为空，请注意空值一列的填写 6、字段精度一列不允许存在括号，如字段类型为 numeric时，字段精度一列为（9，4），这是错误的（二）字段类型与精度 通常用到的字段类型有：1、数值型(numeric)：使用要点：

11、numeric 在技术文档中精度不能加括号，注意考虑精确度。常见用途：A.实体为自然数的，如人、车数目，若量纲为万人，只精确到十位，则需用 NUMERIC。B.比例值 C.数据量、额度型字段 D.排顺序（注意和排名不同）一般见于物殊应用，如CUST_PUB_SECTION_CODE（板块代码表）表，在产品应用层，需对表中板块顺序实现人为编排，“板块顺序”采用 numeric(9,4)初始排序值即不需预留空位，新增或调整个别板块顺序，只需在“板块顺序”上加精确度值，分出大小即可。2、字符型(varchar)：使用要点：varchar 如果超过 400，则应用 text类型 常见用途：A.主要用于

12、存储文字描述形字段；B.像证券市场代码、电话、网址都属于此类 C.附件链接地址等 3、整数型（int）：使用要点：统一使用 int型，可以支持 10位（10亿）常见用途：A.排名形字段，注意“排名次”和排顺序不同，排名主要是排自然数名次，如分析师排名、十大股东排名等，排顺序主要用于隐藏性展示。B.值为自然数的，如人、车数目（若量纲为万人，只精确到十位，则需用NUMERIC）C.一般为内部代码、序号等类型字段 D.参数型字段，即需要和综合参数表关联的字段。E.年份值、月度值等 F.系统字段：SEQISVALID等 4、文本型(text)：使用要点：字符长度超过 400个字节 常见用途：A.字符长

13、度超过 400个字节 5、日期型(datetime)：使用要点：字段用于描述到天的 常见用途：A.截止日期 B.交易日期 C.公告日期 6、其他：smalldatetime 主要用于描述时间点需精确到时分秒类型的数据，如新闻发布日期，系统字段：数据入库时间、修改时间等。（三）字段备注 1、表备注主要是与相关表的关联与一些特别说明，若是特别说明，直接描述；全部为 5号宋体字 2、如果关联相应的表：关联“表名”.“字段名”3、如果关联综合参数表：关联 WHERE CLS_CODE=“分类编码”，可以列举出相应的参数代码-参数名称。部分参数取值类型较少的可以直接全部罗列；参数类型较多的，可以只列举重

14、要参数或用到的参数。【关于关联备注：假设表 T1,T2。T1的字段 f关联 T2的字段 F的时候，通常代表T2中 F字段是主键，T1中 f就是外键。但并不绝对说，如果 T2的字段 F不是主键的时候，就不能备注说明 f是关联字段的。该说法成立的最本质要求是 F字段的每个值在该表中只会有一条记录出现，即各记录的 F字段值是互不相同的。这个时候，说关联它是有意义的。实际应用中，通常只需要对代码类(内部代码、机构代码、参数代码等)字段做关联备注，其他的不需要，也通常不满足上面说的那个前提条件】（四）表的备注 1、综述：表的备注应该尽量完整，主要用于描述表的数据内容、数据存储范畴、数据维护情况、使用注意

15、事项等四个方面进行描述，缺一不可，便于应用开发参考。同时为了保持规范性，要求语言简明扼要，语法应用准确，这是做好数据库专业性的基本要求。表的备注内容在撰写时，应该注意表所针对的阅读者。如 CG表的备注使用者，多是“想查阅表的采集、数据处理相关信息”；而 PG表的备注使用者，多是“想通过表备注来获得数据质量、数据完整性、数据更新及时性、数据内容简界等相关信息”。CG和 PG可能就是完全一一对应的表，但表备注的内容应该是有所差别的。2、表备注备内容要点：表的数据内容：如 STK_MKT（股票行情表），应在表备注中说明“本表用于存储沪深两个交易所股票日行情。”数据存储的范畴：历史数据可追溯到 199

16、0年，1995年以来数据非常完成。数据维护情况：数据来源于沪深交易所对外的行情 DBF，每日收盘后 XX分钟内数据入库。表的数据特征：本表考虑到应用特征，剔除了 DBF中停牌的无效股票行情。使用注意事项：申报买入价 1（BP1）、申报买入量 1（BV1）、申报卖出价 1（SP1）等字段为交易所行情 DBF中相关字段的原始内容，对日行情表来说，一般不会使用到。汇总后的 STK_MKT（股票行情表）表备注内容应为：“本表用于存储沪深交易所股票日盘后行情。历史数据可追溯到 1990年，1995年以来数据非常完成。数据来源于交易所对外发布的行情 DBF，每日收盘后 XX分钟内数据入库。考虑到应用特征，

17、剔除了 DBF中停牌的无效股票行情。表中申报买入价 1（BP1）、申报买入量 1（BV1）、申报卖出价 1（SP1）等字段为交易所行情 DBF中相关字段的原始内容存储，对日行情表来说，一般不会使用到。三、中英文命名的规范性 表和字段英文名命名统一格式为：大写字母、英文缩写加下划线组成 SQL/ORACLE关键字不能作为表名或者字段名 相关命名规则见：C011-表及字段英文名命名规则.doc 四、表结构规范性（一）整体规范性要求（2009-11-30新增）采集库、中心库、产品库设计都应当执行三范式化标准，去除冗余；需参数化字段应尽量参数化；部分特殊字段既需参数化，又需保留其原始披露内容，不是冗余

18、；采集库、中心库都应从内容上考虑数据库设计中的行为特征设计，并不是只管满足采集需求；（二）关联机构库 数据表关联机构库时，将遵循以下原则：采集表必须保留机构名称这个字段，以保存披露的原始信息；不可以使用机构代码作为主键；通常可以使用机构序号作为主键(诸如十大股东、发行相关机构表之类)。无法避免使用时，使用机构名称作为主键；在上面设定的机制下，机构代码可以延后填入，可以避免数据库中机构代码非空或直接设置为主键带来的缺点。让那些采集时无法得到机构代码的机构交由专门负责机构库的采编整理。从而实现机构库专人维护！提高机构库的质量。如果设计的采集表涉及机构，那么表结构通常应该包括如下字段：机构名称或者机

19、构简称 orgname：采集的机构名称/简称记录在其中；机构代码 orgcode：机构组会通过专用工具维护该字段内容；机构代码处理标识 orgcode_mark：给机构代码维护专用工具服务的。该业务表部署的时候需要告知机构组该表有关联机构库，需要机构组把该表纳入业务表机构代码维护平台中。告知的内容要包括：业务表所在库，通常是 CGENIUS;业务表英文名；表中机构代码字段英文名；表中机构名称/简称字段英文名；表中机构代码处理标识字段英文名；扫描条件：如果业务表中只有部分满足一定条件的记录才真正关联机构库，也就是说只有满足该条件的记录才需要维护机构代码，那么需要填写该扫描条件，以便配合机构代码专

20、用工具工作。扫描条件的填写规范：SQL语句的表达式，该语句定义了机构库外延工具中业务表维护工具扫描各业务表的相应扫描条件。(例子：T表中的 F1字段有三个值域1、2、3，只有 F1 IN(1,2)的记录才是关联机构库的，那么扫描条件写为：f1 in(1,2)。更多实例可参见 139.PUBDB.ORG_TBL_CONFIGURE。机构组相关人员接到告知后，配置 139.PUBDB.ORG_TBL_CONFIGURE表格，填入该业务表相关信息，并开始日常维护该表的机构代码。（三）机构代码不可作为主键；1.可用序号(推荐)、或者使用机构名称(不推荐)作为主键；2.但并不是说绝对不允许用机构代码做主

21、键，如果表的内容是以机构为中心、而且该表描述的机构的范围是比较小（绝大部分都应该已经存于我们的机构库中），那么是可以以机构代码做主键的。比如，金融公司财务信息表，该表以金融机构为中心，而且金融机构已经比较完全地维护在机构 库里面了，该表以机构代码为主键是合适的。券商十大股东表，那么该表以券商为中心，券商机构代码为主键是合理的，而对于股东机构代码则不适合作为主键了，因为股东可能非常繁杂，会大量不存于机构库中，那么不做主键就可以快速采集，事后再维护机构代码。（四）数据库的表字段注意事项 1.如果某个字段的内容要以逗号间隔，此逗号为半角逗号 例如：研究报告主表（RES_Report_Main）的“研

22、究员姓名（Analyst）”可能为多个姓名，此时姓名之间要用半角逗号隔开。2.如果某个字段的值用数字代替，那么它的值域要从“1”开始，不能从“0”开始；数字“0”只能表示特殊字段的值。例如：新财富最佳分析主师（RES_BEST_ANALYST_PROFILE）的“新财富名次（New_Forture_Rank）”字段的值：1第一名，2第二名，3第三名；不能用“0”作为“新财富名次”的代码，数字“0”只能表示“是否有效（IsValid）”这种特殊字段。（五）参数字段设计注意事项（200912-31新增）所谓参数字段即数据源披露通常为文字型描述，为了便于产品应用，通过设置有限的取值类型来作量化处理。

23、通常一个参数型字段对应一个参数系，一个参数系可能被多个参数型字段同时引用，但前提是多个参数型字段必要是描述的同一含义的字段。通常参数系、参数取值设置应注意：1.同一个参数系必须是一个维度的。2.同一参数系下的取值类型必段是没有交集。3.同一参数系下所有取值类型并集为全集。4.参数系与参数取值通常用整数型。【如人的分类，可以有如下维度：年龄段、肤色、性别、国别等】（六）原始字段与量化字段同时保存（2009-11-30新增）在设计采集库、中心库甚至产品库时，除确保执行范式化标准外，还应注意一类字段的特殊性。如：上市公司高管职务名称，既要保留原公告披露职务，又要参数化便于统计应用；机构名称，既要保留

24、原公告直接披露的名称，又要在机构库中统一标准化便于统计应用，这与机构库设计和机构代码处理方式是锲合的。基金投资风格，原始披露的风格五花八门需保留满足产品展示，同时还应作量化满足统一应用分析；债券评级级别，原始披露债券信用级别是各不相同，但基本上存在同等的对应关系，则即需保留原始的债券级别标记，又需统一参数化。可能还存在其他类型字段，需细化考虑。（七）公告日期不可作为主键；一条记录通常描述了一个对象，比如一条分红记录。但是公告日期不属于分红本身的属性，公告日期是由信息披露方决定的。极端的时候，有些信息无法得到具体的公告日期。可以序号作为主键替代。（八）名称不能做主键 产品表和采集表应避免用“证券

25、名称”、“机构名称”等作主键，以免带来数据处理的问题。（九）主子表 中心库存储数据时，推荐使用主子表形式，可以减少采集工作量。而产品库设计中，通常将主子表合成为一张表(中心库的主子表主键合并便得到了合成表)，方便应用和客户使用。采集库中的主子表模型:产品库中的表模型（十）量纲 百分比类单位：字段为百分比类比例值或比率值的，量纲一率为%金额类单位：可以用元、万元、亿三类，不允许用“千元”、“百万元”、“千万元”、“十亿”等非法量纲 质量类量纲：克、千克、吨、万吨、亿吨 长度类量纲：米、千米、海里、英里，不允许用“公里”、“里”等非标准类单位。其他类量纲：基金：份、万份 股票：股、万股 债券：张、

26、万张、手（100张）其他：个、件（十一）关联标识 在采集表或少量产品表中存在主子表情况，通常用关联标识与主表 SEQ 关联，新库子表一律统一只能用 P_SEQ 关联，老 DB40库也可以用 VSEQ（十二）字段命名规则 SQL/ORACLE关键字不能作为表名或者字段名 首先通用类表名和字段名规则一律强制执行。非通用类字段英文名缩写要求必须从现有的缩写表中选用，没有的可以补充。对于检查人员则可以任意提取一个缩写到C011-表及字段英文名命名规则.doc中检查，如没有，则视为非法命名。（十三）数据类型的选择 【具体见上述字段类型与精度部分】通常用到的字段类型有：数值型：numeric 在技术文档中

27、精度不能加括号，注意考虑精度。字符型：varchar 如果超过 400，则应用 text类型 整数型：int 一般为内部代码、序号等类型字段 文本型：text字符长度超过 400个字节 日期型：datetime 不在上述范围内的字段类型视为非法类型（十四）字段的精度问题 在当前发现的问题中，很多都是由于字段精确度设置过小，反复修改。所以在设置字段精度时，应该尽量扩大到当前值的 100倍，如 numeric类型，整数位和小数位都多加两位，对数据库本身是没有任何影响的（十五）字段的量化范畴 在设计表时，通常坚持能量化的字段尽量量化（即通常所说有参数化，以便于统计应用）机构类型字段一般应处理成与机构

28、代码表相关联（根据具体情况判断是否与公司表关联）（十六）字段的冗余 Pgenius数据库被定义为中心库，将不允许有冗余字段。目前已有的冗余字段将被清除。一是不符合数据库设计范式，存在数据库中是一个错误；二是技术上难以保障历史数据与当前更新数据的一致性，或者保障成本非常高。1.第一类如下述有了公司代码(或证券内部代码)，再冗余证券代码证券简称的 2.第二类如下述,把参数化的字段,再加一个描述字段冗余 3.第三类如下述，有了机构代码，应关联到机构库则不应把机构类型作冗余。机构类型是用于描述机构，而不是本表的实体“内部代码”（存在特情况，如 10大股东表中的机构属性，是用于描述股东角度的机构类型的，

29、不算冗余字段）。（同时存在机构代码和机构名称，不算冗余，见“原始字段与量化字段同时保存”）4.第四类是指标标的被代码化,然后在产品表中又冗余名称的 5.第五类是行政地域行业等,产品表只已有了内部的代码,不能再有名称官方代码的冗余 如下图所示，产品表中除了行业代码表中允许有行业代码和行业名称名，其他表是不允许有行业代码和行业名称的，只有用行业内部代码。（十七）内部代码化：（2009-12-31新增）在 PG库和 CG库中，行业、地域、板块、指标、证券实体、参数、机构、公司等全部被赋予了内部代码，则 PG产品表中只能用内部代码来关联应用，其他业务表只能和码表用内部代码关联，不允许用官方代码（市场代

30、码）关联。所有业务表（特别是产品表）一般禁止用市场代码作关联；其他业务表中一般不允许出现冗余的行业代码、行业名称，机构名称、公司名称类同；证券的市场代码严格意义上只是证券实体的一个属性，一般只能存在于码表中。七、易犯错误（一）表技术文档不够规范 譬如，中英文名称中间有空格，或者单元格内有回车符、空格等；单元格内容有超链接。这些都会导致数据字典维护人员的工作困难和时间耗费。详细的表技术文档设计规范参见 VSS文档新建数据字典的规范表结构（二）主键设置不合理 策划需要从两个方面深刻理解主键的含义：数据库角度主键是唯一的，一个表通过一个主键可以确定一条记录。业务角度确定业务表使用哪些字段组合作为主键

31、。主键冗余 错误典型案例：例如，同时把公司代码和股票代码设为主键：根据 STK001描述 STOCKCODE、comcode的关系可以知道，STOCKCODE决定了 COMCODE，所以既然 STOCKCODE已经被设置为主键，那么 COMCODE就不需要在被设为主键之一了。（三）主键设置业务上不够合理 过去很多表有设置“公告日期”DECLAREDATE为主键之一。从面向对象的角度来说，公告日期只是描述对象的一个属性。这个时间并不是该对象的本质特征。好比三大财务报表，报表日期、截至日期、(开始日期)、报表类型、公司代码这些都属于报表的本质特征，任何一个不同就代表了不同的记录（财务报表的不同列），而公布日期则不同。公布日期是由信息披露方决定的，他今天公布财务报表或者明天公布财务报表并不该表财务报表对象的本身特征/内容。它只是财务报表的一个附属属性。包括分红信息表，公布日期也只是一个属性。业务中，如果发现离开公布日期后很难找到一个替代的主键，那么可以引入序号这个字段。标识了是第几次分红。这个信息对产品应用也是很有用处的。