策划案标准与规范.docx
《策划案标准与规范.docx》由会员分享，可在线阅读，更多相关《策划案标准与规范.docx（23页珍藏版）》请在冰点文库上搜索。
策划案标准与规范
策划案规范与标准
一、策划案的结构规范性
（一）策划案的格式与内容
1、采集表策划案内容：
一、简明描述
1、简介：
说明表存储的数据内容、主要用途、使用说明等。
2、来源：
说明表的数据来源,如从某网站采集、通过哪些表计算出来的等
3、维护时间及频率：
说明表的数据更新频率及时间，如每日几点自动触发更新，人工每天几点采集入库
4、重要字段及数据情况：
说明本表的一些重要字段，这些重要字段及所有字段的数据维护情况，数据质量，历史数据情况。
二、表结构（技术文档）（见策划案的规范及标准）
2、产品表策划案内容：
（通用）
一、简明描述
1、简介：
说明表存储的数据内容、主要用途、使用说明等。
2、来源：
说明表的数据来源,如从某网站采集、通过哪些表计算出来的等
3、维护时间及频率：
说明表的数据更新频率及时间，如每日几点自动触发更新，人工每天几点采集入库
4、重要字段及数据情况：
说明本表的一些重要字段，这些重要字段及所有字段的数据维护情况，数据质量，历史数据情况。
二、表结构（技术文档）（见策划案的规范及标准）
（二）策划案的规范及标准
新的表结构主要是配合新的字典工具而设置，如果新建表需要利用新的字典工具，则一定要按照新的表结构策划表，目前可以利用新工具建表的库有CGENIUS和PGENIUS。
标准的表结构：
（新）
基金综合信息表（FND_GEN_INFO）
序号
中文名
英文名
类型
精度
空值
缺省值
量纲
备注
入库方式
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-保本基金关联；6-新基金成立；7-基金管理人变更；8-封闭期结束；9-基金名称变更；10-同级基金关联
采集
5
基本信息
LABEL0101
采集
6
基金代码
FUND_CODE
varchar
12
NO
基金实际交易代码
采集
7
ISIN编码
ISIN
VARCHAR
12
YES
采集
8
深市行情代码
SZSE_CODE
varchar
12
YES
对于封闭式基金，行情代码＝基金代码
采集
9
沪市行情代码
SHSE_CODE
varchar
12
YES
对于封闭式基金，行情代码＝基金代码
采集
10
前端申购代码
APPL_BUY_CODE_FRONT
varchar
12
YES
采集
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
varchar
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
关联：
ORG_PROFILE.OrgCode
采集
22
基金机构代码处理标识
ORG_CODE_MARK
INT
YES
关联GEN_REF.REF_CODEWHERECLS_CODE=13
23
管理人代码
MANA_CODE
int
YES
关联：
ORG_PROFILE.OrgCode
采集
24
管理人代码处理标识
MANA_CODE_MARK
INT
YES
关联：
GEN_REF.REF_CODEWHERECLS_CODE=13
25
管理人名称
MANA_NAME
varchar
200
YES
采集
26
货币型基金红利计提和分配方式
CURNCY_DISTIL_CLS
int
YES
红利计提方式（TRADE_MKT）与“综合参数表（GEN_REF）”表中的“参数代码（REF_CODE）”关联，“CLS_CODE=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
？
基金初始成立日期，可追溯到基金转型前、分级前的最早设立日期
采集
主码特性:
基金内部代码+变动日期
唯一索引：
备注：
货币型基金一般存在红利计提方式（按日按月）、收益分配方式（按日按月）、收益结转份额方式（按日按月）、收益支付方式（按日按月）四种说法，目前各基金公司在基金合同中并未给出明确、一致的表达方式。
其中红利计提方式与收益支付方式一般都是一般都是按月计提分配。
收益结转份额方式各不相同。
收益支付方式一般为按月集中支付。
本表记录了基金成立、转型、分级、保本期变更、管理人变更、基金名称变更等基金成立以来的变动情况。
----------------------------------------------------------------------------------------------------------------------
二、技术文档的规范性
（一）格式要点：
1、为了策划案的统一规则性，整个技术文档必须用“宋体五号字”，所有内容中不允许有“超级链接”
1、序号必须完整，这是对以后数据字典的WEB版而言的完整性的维护，但是不能采用特殊的文本格式，必须无文本格式
2、字段类型若为INT和DATETIME时，字段精度为空
3、在字段备注中不允许存在“段落标记”——回车键，在表结构中都不允许存在的
4、主键采用“黄色”底纹标注，同时在主码特性中必须与标注的一样，同时存在几个主键时，字段名中间用+，如“公司代码+报表日期+项目代码”
5、主键字段不允许为空，请注意空值一列的填写
6、字段精度一列不允许存在括号，如字段类型为numeric时，字段精度一列为（9，4），这是错误的
（二）字段类型与精度
通常用到的字段类型有：
1、数值型（numeric）：
使用要点：
numeric在技术文档中精度不能加括号，注意考虑精确度。
常见用途：
A.实体为自然数的，如人、车数目，若量纲为万人，只精确到十位，则需用NUMERIC。
B.比例值
C.数据量、额度型字段
D.排顺序（注意和排名不同）一般见于物殊应用，如CUST_PUB_SECTION_CODE（板块代码表）表，在产品应用层，需对表中板块顺序实现人为编排，“板块顺序”采用numeric（9,4）初始排序值即不需预留空位，新增或调整个别板块顺序，只需在“板块顺序”上加精确度值，分出大小即可。
2、字符型（varchar）：
使用要点：
varchar如果超过400，则应用text类型
常见用途：
A.主要用于存储文字描述形字段；
B.像证券市场代码、电话、网址都属于此类
C.附件链接地址等
3、整数型（int）：
使用要点：
统一使用int型，可以支持10位（10亿）
常见用途：
A.排名形字段，注意“排名次”和排顺序不同，排名主要是排自然数名次，如分析师排名、十大股东排名等，排顺序主要用于隐藏性展示。
B.值为自然数的，如人、车数目（若量纲为万人，只精确到十位，则需用NUMERIC）
C.一般为内部代码、序号等类型字段
D.参数型字段，即需要和综合参数表关联的字段。
E.年份值、月度值等
F.系统字段：
SEQ\ISVALID等
4、文本型（text）：
使用要点：
字符长度超过400个字节
常见用途：
A.字符长度超过400个字节
5、日期型（datetime）：
使用要点：
字段用于描述到天的
常见用途：
A.截止日期
B.交易日期
C.公告日期
6、其他：
smalldatetime主要用于描述时间点需精确到时分秒类型的数据，如新闻发布日期，系统字段：
数据入库时间、修改时间等。
（三）字段备注
1、表备注主要是与相关表的关联与一些特别说明，若是特别说明，直接描述；全部为5号宋体字
2、如果关联相应的表：
关联“表名”.“字段名”
3、如果关联综合参数表：
关联GEN_REF.CLS_CODEWHERECLS_CODE=“分类编码”，可以列举出相应的参数代码-参数名称。
部分参数取值类型较少的可以直接全部罗列；参数类型较多的，可以只列举重要参数或用到的参数。
【关于关联备注：
假设表T1,T2。
T1的字段f关联T2的字段F的时候，通常代表T2中F字段是主键，T1中f就是外键。
但并不绝对说，如果T2的字段F不是主键的时候，就不能备注说明f是关联T2.F字段的。
该说法成立的最本质要求是F字段的每个值在该表中只会有一条记录出现，即各记录的F字段值是互不相同的。
这个时候，说T1.f关联它是有意义的。
实际应用中，通常只需要对代码类（内部代码、机构代码、参数代码等）字段做关联备注，其他的不需要，也通常不满足上面说的那个前提条件】
（四）表的备注
1、综述：
表的备注应该尽量完整，主要用于描述表的数据内容、数据存储范畴、数据维护情况、使用注意事项等四个方面进行描述，缺一不可，便于应用开发参考。
同时为了保持规范性，要求语言简明扼要，语法应用准确，这是做好数据库专业性的基本要求。
表的备注内容在撰写时，应该注意表所针对的阅读者。
如CG表的备注使用者，多是“想查阅表的采集、数据处理相关信息”；而PG表的备注使用者，多是“想通过表备注来获得数据质量、数据完整性、数据更新及时性、数据内容简界等相关信息”。
CG和PG可能就是完全一一对应的表，但表备注的内容应该是有所差别的。
2、表备注备内容要点：
表的数据内容：
如STK_MKT（股票行情表），应在表备注中说明“本表用于存储沪深两个交易所股票日行情。
”
数据存储的范畴：
历史数据可追溯到1990年，1995年以来数据非常完成。
数据维护情况：
数据来源于沪深交易所对外的行情DBF，每日收盘后XX分钟内数据入库。
表的数据特征：
本表考虑到应用特征，剔除了DBF中停牌的无效股票行情。
使用注意事项：
申报买入价1（BP1）、申报买入量1（BV1）、申报卖出价1（SP1）……等字段为交易所行情DBF中相关字段的原始内容，对日行情表来说，一般不会使用到。
汇总后的STK_MKT（股票行情表）表备注内容应为：
“本表用于存储沪深交易所股票日盘后行情。
历史数据可追溯到1990年，1995年以来数据非常完成。
数据来源于交易所对外发布的行情DBF，每日收盘后XX分钟内数据入库。
考虑到应用特征，剔除了DBF中停牌的无效股票行情。
表中申报买入价1（BP1）、申报买入量1（BV1）、申报卖出价1（SP1）……等字段为交易所行情DBF中相关字段的原始内容存储，对日行情表来说，一般不会使用到。
三、中英文命名的规范性
表和字段英文名命名统一格式为：
大写字母、英文缩写加下划线组成
SQL/ORACLE关键字不能作为表名或者字段名
相关命名规则见：
《C011-表及字段英文名命名规则.doc》
四、表结构规范性
（一）整体规范性要求（2009-11-30新增）
●采集库、中心库、产品库设计都应当执行三范式化标准，去除冗余；
●需参数化字段应尽量参数化；
●部分特殊字段既需参数化，又需保留其原始披露内容，不是冗余；
●采集库、中心库都应从内容上考虑数据库设计中的行为特征设计，并不是只管满足采集需求；
（二）关联机构库
数据表关联机构库时，将遵循以下原则：
✧采集表必须保留机构名称这个字段，以保存披露的原始信息；
✧不可以使用机构代码作为主键；
通常可以使用机构序号作为主键（诸如十大股东、发行相关机构表之类）。
✧无法避免使用时，使用机构名称作为主键；
在上面设定的机制下，机构代码可以延后填入，可以避免4.0数据库中机构代码非空或直接设置为主键带来的缺点。
让那些采集时无法得到机构代码的机构交由专门负责机构库的采编整理。
从而实现机构库专人维护！
提高机构库的质量。
如果设计的采集表涉及机构，那么表结构通常应该包括如下字段：
●机构名称或者机构简称orgname：
采集的机构名称/简称记录在其中；
●机构代码orgcode：
机构组会通过专用工具维护该字段内容；
●机构代码处理标识orgcode_mark：
给机构代码维护专用工具服务的。
该业务表部署的时候需要告知机构组该表有关联机构库，需要机构组把该表纳入业务表机构代码维护平台中。
告知的内容要包括：
◆业务表所在库，通常是CGENIUS;
◆业务表英文名；
◆表中机构代码字段英文名；
◆表中机构名称/简称字段英文名；
◆表中机构代码处理标识字段英文名；
◆扫描条件：
如果业务表中只有部分满足一定条件的记录才真正关联机构库，也就是说只有满足该条件的记录才需要维护机构代码，那么需要填写该扫描条件，以便配合机构代码专用工具工作。
扫描条件的填写规范：
SQL语句的表达式，该语句定义了机构库外延工具中业务表维护工具扫描各业务表的相应扫描条件。
（例子：
T表中的F1字段有三个值域——1、2、3，只有F1IN（1,2）的记录才是关联机构库的，那么扫描条件写为：
f1in（1,2））。
更多实例可参见139..PUBDB..ORG_TBL_CONFIGURE。
机构组相关人员接到告知后，配置139..PUBDB..ORG_TBL_CONFIGURE表格，填入该业务表相关信息，并开始日常维护该表的机构代码。
（三）机构代码不可作为主键；
1.可用序号（推荐）、或者使用机构名称（不推荐）作为主键；
2.但并不是说绝对不允许用机构代码做主键，如果表的内容是以机构为中心、而且该表描述的机构的范围是比较小（绝大部分都应该已经存于我们的机构库中），那么是可以以机构代码做主键的。
比如，金融公司财务信息表，该表以金融机构为中心，而且金融机构已经比较完全地维护在机构
库里面了，该表以机构代码为主键是合适的。
券商十大股东表，那么该表以券商为中心，券商机构代码为主键是合理的，而对于股东机构代码则不适合作为主键了，因为股东可能非常繁杂，会大量不存于机构库中，那么不做主键就可以快速采集，事后再维护机构代码。
（四）数据库的表字段注意事项
1.如果某个字段的内容要以逗号间隔，此逗号为半角逗号
例如：
研究报告主表（RES_Report_Main）的“研究员姓名（Analyst）”可能为多个姓名，此时姓名之间要用半角逗号隔开。
2.如果某个字段的值用数字代替，那么它的值域要从“1”开始，不能从“0”开始；
数字“0”只能表示特殊字段的值。
例如：
新财富最佳分析主师（RES_BEST_ANALYST_PROFILE）的“新财富名次（New_Forture_Rank）”字段的值：
1－第一名，2－第二名，3－第三名；不能用“0”作为“新财富名次”的代码，数字“0”只能表示“是否有效（IsValid）”这种特殊字段。
（五）参数字段设计注意事项（2009－12-31新增）
所谓参数字段即数据源披露通常为文字型描述，为了便于产品应用，通过设置有限的取值类型来作量化处理。
通常一个参数型字段对应一个参数系，一个参数系可能被多个参数型字段同时引用，但前提是多个参数型字段必要是描述的同一含义的字段。
通常参数系、参数取值设置应注意：
1.同一个参数系必须是一个维度的。
2.同一参数系下的取值类型必段是没有交集。
3.同一参数系下所有取值类型并集为全集。
4.参数系与参数取值通常用整数型。
【如人的分类，可以有如下维度：
年龄段、肤色、性别、国别等】
（六）原始字段与量化字段同时保存（2009-11-30新增）
在设计采集库、中心库甚至产品库时，除确保执行范式化标准外，还应注意一类字段的特殊性。
如：
①上市公司高管职务名称，既要保留原公告披露职务，又要参数化便于统计应用；
②机构名称，既要保留原公告直接披露的名称，又要在机构库中统一标准化便于统计应用，这与机构库设计和机构代码处理方式是锲合的。
③基金投资风格，原始披露的风格五花八门需保留满足产品展示，同时还应作量化满足统一应用分析；
④债券评级级别，原始披露债券信用级别是各不相同，但基本上存在同等的对应关系，则即需保留原始的债券级别标记，又需统一参数化。
可能还存在其他类型字段，需细化考虑。
（七）公告日期不可作为主键；
一条记录通常描述了一个对象，比如一条分红记录。
但是公告日期不属于分红本身的属性，公告日期是由信息披露方决定的。
极端的时候，有些信息无法得到具体的公告日期。
可以序号作为主键替代。
（八）名称不能做主键
产品表和采集表应避免用“证券名称”、“机构名称”等作主键，以免带来数据处理的问题。
（九）主子表
中心库存储数据时，推荐使用主子表形式，可以减少采集工作量。
而产品库设计中，通常将主子表合成为一张表（中心库的主子表主键合并便得到了合成表），方便应用和客户使用。
采集库中的主子表模型:
产品库中的表模型
（十）量纲
百分比类单位：
字段为百分比类比例值或比率值的，量纲一率为%
金额类单位：
可以用元、万元、亿三类，不允许用“千元”、“百万元”、“千万元”、“十亿”等非法量纲
质量类量纲：
克、千克、吨、万吨、亿吨
长度类量纲：
米、千米、海里、英里，不允许用“公里”、“里”等非标准类单位。
其他类量纲：
基金：
份、万份
股票：
股、万股
债券：
张、万张、手（100张）
其他：
个、件
（十一）关联标识
在采集表或少量产品表中存在主子表情况，通常用关联标识与主表SEQ关联，新库子表一律统一只能用P_SEQ关联，老DB40库也可以用VSEQ
（十二）字段命名规则
SQL/ORACLE关键字不能作为表名或者字段名
首先通用类表名和字段名规则一律强制执行。
非通用类字段英文名缩写要求必须从现有的缩写表中选用，没有的可以补充。
对于检查人员则可以任意提取一个缩写到《C011-表及字段英文名命名规则.doc》中检查，如没有，则视为非法命名。
（十三）数据类型的选择
【具体见上述字段类型与精度部分】
通常用到的字段类型有：
数值型：
numeric在技术文档中精度不能加括号，注意考虑精度。
字符型：
varchar如果超过400，则应用text类型
整数型：
int一般为内部代码、序号等类型字段
文本型：
text字符长度超过400个字节
日期型：
datetime
不在上述范围内的字段类型视为非法类型
（十四）字段的精度问题
在当前发现的问题中，很多都是由于字段精确度设置过小，反复修改。
所以在设置字段精度时，应该尽量扩大到当前值的100倍，如numeric类型，整数位和小数位都多加两位，对数据库本身是没有任何影响的
（十五）字段的量化范畴
在设计表时，通常坚持能量化的字段尽量量化（即通常所说有参数化，以便于统计应用）
机构类型字段一般应处理成与机构代码表相关联（根据具体情况判断是否与公司表关联）
（十六）字段的冗余
Pgenius数据库被定义为中心库，将不允许有冗余字段。
目前已有的冗余字段将被清除。
一是不符合数据库设计范式，存在数据库中是一个错误；二是技术上难以保障历史数据与当前更新数据的一致性，或者保障成本非常高。
1.第一类如下述有了公司代码（或证券内部代码），再冗余证券代码\证券简称的
2.第二类如下述,把参数化的字段,再加一个描述字段冗余
3.第三类如下述，有了机构代码，应关联到机构库则不应把机构类型作冗余。
机构类型是用于描述机构，而不是本表的实体“内部代码”（存在特情况，如10大股东表中的机构属性，是用于描述股东角度的机构类型的，不算冗余字段）。
（同时存在机构代码和机构名称，不算冗余，见“原始字段与量化字段同时保存”）
4.第四类是指标标的\被代码化,然后在产品表中又冗余名称的
5.第五类是行政\地域\行业等,产品表只已有了内部的代码,不能再有名称\官方代码的冗余
如下图所示，产品表中除了行业代码表中允许有行业代码和行业名称名，其他表是不允许有行业代码和行业名称的，只有用行业内部代码。
（十七）内部代码化：
（2009-12-31新增）
在PG库和CG库中，行业、地域、板块、指标、证券实体、参数、机构、公司等全部被赋予了内部代码，则PG产品表中只能用内部代码来关联应用，其他业务表只能和码表用内部代码关联，不允许用官方代码（市场代码）关联。
Ø所有业务表（特别是产品表）一般禁止用市场代码作关联；
Ø其他业务表中一般不允许出现冗余的行业代码、行业名称，机构名称、公司名称类同；
Ø证券的市场代码严格意义上只是证券实体的一个属性，一般只能存在于码表中。
七、易犯错误
（一）表技术文档不够规范
譬如，中英文名称中间有空格，或者单元格内有回车符、空格等；
单元格内容有超链接。
这些都会导致数据字典维护人员的工作困难和时间耗费。
详细的表技术文档设计规范参见VSS文档——《新建数据字典的规范表
升级会员 