策划案的规范与标准.doc

策划案的规范与标准

28
2020年5月29日
文档仅供参考
策划案规范与标准
一、策划案的结构规范性
(一)策划案的格式与内容
1、采集表策划案内容:
一、简明描述
1、简介:说明表存储的数据内容、主要用途、使用说明等。
2、来源:说明表的数据来源,如从某网站采集、经过哪些表计算出来的等
3、维护时间及频率:说明表的数据更新频率及时间,如每日几点自动触发更新,人工每天几点采集入库
4、重要字段及数据情况:说明本表的一些重要字段,这些重要字段及所有字段的数据维护情况,数据质量,历史数据情况。

二、表结构(技术文档)(见策划案的规范及标准)

2、产品表策划案内容:(通用)
一、简明描述
1、简介:说明表存储的数据内容、主要用途、使用说明等。
2、来源:说明表的数据来源,如从某网站采集、经过哪些表计算出来的等
3、维护时间及频率:说明表的数据更新频率及时间,如每日几点自动触发更新,人工每天几点采集入库
4、重要字段及数据情况:说明本表的一些重要字段,这些重要字段及所有字段的数据维护情况,数据质量,历史数据情况。

二、表结构(技术文档)(见策划案的规范及标准)

(二)策划案的规范及标准
新的表结构主要是配合新的字典工具而设置,如果新建表需要利用新的字典工具,则一定要按照新的表结构策划表,当前能够利用新工具建表的库有CGENIUS和PGENIUS。
标准的表结构:(新)

基金综合信息表(FND_GEN_INFO)注意表头格式:表中文名+(表英文名),注意括号用英文状态括号,否则计算机构可能识别不要,且不能有空格

序号
中文名
英文名
类型
精度
空值
缺省值
量纲
备注
入库方式表头列的顺序及列中文名不能随便改动,注意用灰色底纹。

1
基金标识
FUND_ID
int内部代码类、机构代码字段都统一用int型(DB40中都统一用的varchar类型)

YES

转型基金、分级基金、保本基金等基金标识相同
采集
2
基金内部代码
INNER_CODE
int

NO主键字段不能为空

赋予内部使用的代码,转型前后相同
采集
3
变动日期
CHANGEDATE
datetime

NO

基金发生变动的公告日期采集表和产品表的主键一律用深黄底纹标识

采集
4
变动原因
CHNG_REASON
int参数型字段统一用int型

YES

变动原因(CHNG_REASON)与”综合参数表(GEN_REF)”表中的”参数代码(REF_CODE)”关联,”CLS_CODE=3006”,得到基金类型的具体描述:1-封转开;2-开转开;3-基金分级;4-基金复制;5-保本基金关联;6-新基金成立;7-基金管理人变更;8-封闭期结束;9-基金名称变更;10-同级基金关联
采集
5
基本信息
LABEL0101

采集采集表和产品表技术文档中都能够加入类似的标签字段,以便客户在看技术文档时更方便。标签字段英文名一律用”LABLE”开头,用两位代码来表示层级关系,在技术文档中,这类字段都有灰色底纹。

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行情、交易类代码,一律使用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

采集在PG产品表中是不允许这这样的冗余字段

21
基金机构代码
ORG_CODE
INT

YES

关联:ORG_PROFILE.OrgCode
采集
22
基金机构代码处理标识
ORG_CODE_MARK
INT

YES

关联GEN_REF.REF_CODE WHERE CLS_CODE=13采集表机构标识,用于机构组维护相关机构时使用

23
管理人代码
MANA_CODE
int

YES

关联:ORG_PROFILE.OrgCode新PG数据库的公用表只有几大类:综合参数表、机构表、公司表、行业参数表、地域参数表

采集
24
管理人代码处理标识
MANA_CODE_MARK
INT

YES

关联:GEN_REF.REF_CODE WHERE CLS_CODE=13采集表机构标识,用于机构组维护相关机构时使用

25
管理人名称
MANA_NAME
varchar
200
YES

采集在采集表中,采集员维护机构名称,由机构组机构处理标识去查找并维护机构代码,在PG产品表中是不能有这种冗余的.

26
货币型基金红利计提和分配方式
CURNCY_DISTIL_CLS
int

YES

红利计提方式(TRADE_MKT)与”综合参数表(GEN_REF)”表中的”参数代码(REF_CODE)”关联,”CLS_CODE=3002”,得到红利计提方式的具体描述:0-其它;1-按日;2-按月在参数的设置中,一般将0这个取值默认为其它、不详、不明等类型,在采集界面上应该尽量把”0”这类取值去掉,以避免采集员的不规范操作。

采集
27
相关日期
LABEL0102

采集
28
设立日期
ESTAB_DATE
datetime日期、日期时间型字段全部统一用datetime类型

YES

基金发生变动后的设立日期(如转型、分级、保本续期、封闭期结束等)
采集
29
上市日期
LIST_DATE
datetime

YES

采集
30
基金到期日
FUND_MATU
datetime

YES

采集
31
存续期限
DURATION
numeric
9,4
YES

年注意量纲的规范性和完整性

采集
32
初始设立日期
INIT_ESTAB_DATE
datetime

YES
?有时有些字段需要设置默认值,即当其为空时,系统自动给其赋的值

基金初始成立日期,可追溯到基金转型前、分级前的最早设立日期
采集
主码特性:”主码特性:”为计算机可识别标准格式,后面不能有空格,直接把主键字段中文名用”+”连接起来;注意”主码特性”四个特殊字符集,及连接格式。
基金内部代码+变动日期
唯一索引:”唯一索引:”为计算机可识别标准格式,后面不能有空格,注意”冒号”不要省了,唯一索引相当于候选索引,能够充当外键,但PG库一般不使用

备注:货币型基金一般存在红利计提方式(按日按月)、收益分配方式(按日按月)、收益结转份额方式(按日按月)、收益支付方式(按日按月)四种说法,当前各基金公司在基金合同中并未给出明确、一致的表示方式。其中红利计提方式与收益支付方式一般都是一般都是按月计提分配。收益结转份额方式各不相同。收益支付方式一般为按月集中支付。本表记录了基金成立、转型、分级、保本期变更、管理人变更、基金名称变更等基金成立以来的变动情况。表的备注应该尽量完整,主要用于描述表的数据内容、数据维护情况或本表使用特征等,便于使用者阅读。

----------------------------------------------------------------------------------------------------------------------

二、技术文档的规范性
(一)格式要点:
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_CODE WHERE CLS_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>
四、表结构规范性
(一)整体规范性要求( -11-30新增)
l 采集库、中心库、产品库设计都应当执行三范式化标准,去除冗余;
l 需参数化字段应尽量参数化;
l 部分特殊字段既需参数化,又需保留其原始披露内容,不是冗余;见(五)原始字段与量化字段同时保存

l 采集库、中心库都应从内容上考虑数据库设计中的行为特征设计,并不是只管满足采集需求见上一条
;

(二)关联机构库
数据表关联机构库时,将遵循以下原则:
² 采集表必须保留机构名称这个字段,以保存披露的原始信息; 在4.0数据库中,有不少表采集表没有设置机构名称这个字段。一旦数据采集完毕,披露的机构名称这个原始信息就不存于数据表中,只能透过机构代码来得到。可是一旦机构代码出现紊乱的状况、或者机构库代码更新的变化未能及时更新到数据表时,则再也难以根据数据表中的机构代码得到正确的机构信息了。

² 不能够使用机构代码作为主键;
一般能够使用机构序号作为主键(诸如十大股东、发行相关机构表之类)。
² 无法避免使用时,使用机构名称作为主键;

在上面设定的机制下,机构代码能够延后填入,能够避免4.0数据库中机构代码非空或直接设置为主键带来的缺点 在4.0数据库中,有些数据表关联机构库时直接使用机构代码作为主键或者以非空的形式出现。这样数据表采集人员必须当即处理该机构,为该机构返回机构代码。在这样的情况下,导致机构库维护人数和范围大大扩大,而且在采集及时性的要求下,对机构的整理难免会粗糙起来。使得犯以下两类错误的概率大为增加:(1)关联不到机构但实际存在的,依然在重要机构表中增加了一条新记录和机构代码;(2)关联到了系列机构,但并非实质同一实体却误判为同一机构,直接引用该机构代码采集入表。
。让那些采集时无法得到机构代码的机构交由专门负责机构库的采编整理。从而实现机构库专人维护!提高机构库的质量。

如果设计的采集表涉及机构,那么表结构一般应该包括如下字段:
l 机构名称或者机构简称orgname:采集的机构名称/简称记录在其中;
l 机构代码orgcode:机构组会经过专用工具维护该字段内容;
l 机构代码处理标识orgcode_mark:给机构代码维护专用工具服务的。

该业务表部署的时候需要告知机构组该表有关联机构库,需要机构组把该表纳入业务表机构代码维护平台中。告知的内容要包括:
u 业务表所在库,一般是CGENIUS;
u 业务表英文名;
u 表中机构代码字段英文名;
u 表中机构名称/简称字段英文名;
u 表中机构代码处理标识字段英文名;
u 扫描条件:如果业务表中只有部分满足一定条件的记录才真正关联机构库,也就是说只有满足该条件的记录才需要维护机构代码,那么需要填写该扫描条件,以便配合机构代码专用工具工作。扫描条件的填写规范: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. 但并不是说绝对不允许用机构代码做主键,如果表的内容是以机构为中心、而且该表描述的机构的范围是比较小(绝大部分都应该已经存于我们的机构库中),那么是能够以机构代码做主键的。

比如,金融公司财务信息表,该表以金融机构为中心,而且金融机构已经比较完全地维护在机构
库里面了,该表以机构代码为主键是合适的。

券商十大股东表,那么该表以券商为中心,券商机构代码为主键是合理的,而对于股东机构代码则不适合作为主键了,因为股东可能非常繁杂,会大量不存于机构库中,那么不做主键就能够快速采集,事后再维护机构代码。
(四)数据库的表字段注意事项
1.如果某个字段的内容要以逗号间隔,此逗号为半角逗号
例如:研究报告主表(RES_Report_Main)的”研究员姓名(Analyst)”可能为多个姓名,此时姓名之间要用半角逗号隔开。
2.如果某个字段的值用数字代替,那么它的值域要从”1”开始,不能从”0”开始;
数字”0”只能表示特殊字段的值。
例如:新财富最佳分析主师(RES_BEST_ANALYST_PROFILE)的”新财富名次(New_Forture_Rank)”字段的值:1－第一名,2－第二名,3－第三名;不能用”0”作为”新财富名次”的代码,数字”0”只能表示”是否有效(IsValid)”这种特殊字段。
(五)参数字段设计注意事项( －12-31新增)
所谓参数字段即数据源披露一般为文字型描述,为了便于产品应用,经过设置有限的取值类型来作量化处理。一般一个参数型字段对应一个参数系,一个参数系可能被多个参数型字段同时引用,但前提是多个参数型字段必要是描述的同一含义的字段。一般参数系、参数取值设置应注意:
1. 同一个参数系必须是一个维度的。
2. 同一参数系下的取值类型必段是没有交集。
3. 同一参数系下所有取值类型并集为全集。
4. 参数系与参数取值一般见整数型。
【如人的分类,能够有如下维度:年龄段、肤色、性别、国别等】

(六)原始字段与量化字段同时保存( -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. 第五类是行政\地域\行业等,产品表只已有了内部的代码,不能再有名称\官方代码的冗余
如下图所示,产品表中除了行业代码表中允许有行业代码和行业名称名,其它表是不允许有行业代码和行业名称的,只有用行业内部代码。

(十七)内部代码化:( -12-31新增)
在PG库和CG库中,行业、地域、板块、指标、证券实体、参数、机构、公司等全部被赋予了内部代码,则PG产品表中只能用内部代码来关联应用,其它业务表只能和码表用内部代码关联,不允许用官方代码(市场代码)关联。
Ø 所有业务表(特别是产品表)一般禁止用市场代码作关联;
Ø 其它业务表中一般不允许出现冗余的行业代码、行业名称,机构名称、公司名称类同;
Ø 证券的市场代码严格意义上只是证券实体的一个属性,一般只能存在于码表中。
七、易犯错误
(一)表技术文档不够规范
譬如,中英文名称中间有空格,或者单元格内有回车符、空格等;
单元格内容有超链接。

这些都会导致数据字典维护人员的工作困难和时间耗费。
详细的表技术文档设计规范参见VSS文档——<新建数据字典的规范表结构>

(二)主键设置不合理
策划需要从两个方面深刻理解主键的含义:
数据库角度——主键是唯一的,一个表经过一个主键能够确定一条记录。
业务角度——确定业务表使用哪些字段组合作为主键。

n 主键冗余

错误典型案例:
例如,同时把公司代码和股票代码设为主键:
根据STK001描述STOCKCODE、comcode的关系能够知道,STOCKCODE决定了COMCODE,因此既然STOCKCODE已经被设置为主键,那么COMCODE就不需要在被设为主键之一了。

(三)主键设置业务上不够合理
过去很多表有设置”公告日期”DECLAREDATE为主键之一。
从面向对象的角度来说,公告日期只是描述对象的一个属性。这个时间并不是该对象的本质特征。
好比三大财务报表,报表日期、截至日期、(开始日期)、报表类型、公司代码这些都属于报表的本质特征,任何一个不同就代表了不同的记录(财务报表的不同列),而公布日期则不同。公布日期是由信息披露方决定的,她今天公布财务报表或者明天公布财务报表并不该表财务报表对象的本身特征/内容。它只是财务报表的一个附属属性。
包括分红信息表,公布日期也只是一个属性。业务中,如果发现离开公布日期后很难找到一个替代的主键,那么能够引入序号这个字段。标识了是第几次分红。这个信息对产品应用也是很有用处的。