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