当前位置:文档之家› 项目数据字典

项目数据字典

项目数据字典
项目数据字典

数据字典1.数据库结构参数表

1.1. CCS认可隔声性能测试

1.2. 柴油机噪声源数据

1.3. 隔声装置声学性能测试

1.4. 混响室法隔声结构声学性能测试

1.5. 混响室法吸声性能测试

1.6. 阻抗管法隔声结构声学性能测试

1.7. 阻抗管法吸声性能测试

软件工程-数据库设计规范与命名规则

数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指:对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据, 满足用户信息要求和处理要求。 数据库设计的各阶段: A、需求分析阶段:综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段:形成独立于机器和各DBMS产品的概念模式(信息世界模型),用E-R图来描述。 C、在逻辑设计阶段:将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式。 然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段:根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1. 需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点:调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis, 简称SA方法)从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary,简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点: (1) 具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解,是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法,它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术, 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:

数据库设计和编码规范

数据库设计和编码规范 Version

目录

简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错,保持团队支持顺畅,系统长久使用后不至于紊乱,让管理者易于在众多对象中,获取所需或理清问题。 同时,定义标准程序也需要团队合作,讨论出大家愿意遵循的规范。随着时间演进,还需要逐步校订与修改规范,让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契,而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户,如数据库管理员、程序设计人员和程序开发人员,可以直观地辨识对象用途。而命名规则大都约定俗成,可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例,让用户混淆自定义对象和系统对象或关键词。 例如,存储过程不要以sp_或xp_开头,因为SQL SERVER的系统存储过程以 sp_开头,扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略,要让对象的用途直观易懂,但也不宜过长,造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定,数据库对象包括表、视图(查询)、存储过程(参数查询)、函数、约束。对象名字由前缀和实际名字组成,长度不超过30。避免中文和保留关键字,做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串,而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范,通过后严格按照要求实施。例如:

管家婆数据字典

管家婆数据库表 名称代码 职员信息表employee 库存商品信息表Ptype 往来单位btype 摘要表Abstract 地区信息表AreaType 会计科目表atypecw 仓库信息表Stock 部门信息表Department 订单索引表DlyndxOrder 订单明细表BakDlyOrder 单据索引表Dlyndx 进货单明细表Dlybuy 销售单明细表BakDlyOrder 零售单索引表Dlyndxretail 零售单明细表Dlyretail 其他单据明细表(比如调拨单,收.付款等) Dlyother 凭证明细表Dlya 操作员表Loginuser 系统初始值表Sysdata 系统配置表Syscon 单据配置表vchcon 单据类型表Vchtype 自动盘赢盘亏表CheckedCount 列配置表ColConfig 商品库存分布表GoodsStocks 期初商品库存分布表IniGoodsStocks 库存上下限报警设置表GoodsWar 客户跟踪价格表Price 期初发货、委托、受托商品库存表IniCommission 发货、委托、受托商品库存表Commission 发货结算单明细表Sendjsdly 固定资产基本信息表(包括固定资产类别、增减方式、使 Fixbasic 用状况) 固定资产减少Fixdel 固定资产折旧明细FixDepDetail 固定资产明细表FixDetail 会计期间表MonthProc 期初借进借出商品表Lendborrow00 借进借出商品表Lendborrow 门店登记信息表Posinfo

常用表中的主要字段介绍 1.商品信息库(ptype) 注:销售退货取的入库商品的成本首先取最近加价值(recprice),如果没有的话才取当前库存成本值. 2.往来单位信息库(btype) 与商品信息库相同的字段这里就不介绍了

数据库设计方法、规范与技巧

数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求),在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式(信息世界模型),用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1. 需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis,简称SA方法)从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary,简称DD)来描述。 数据字典是各类数据描述的集合,它是关于数据库中数据的描述,即元数据,而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述={数据项名,数据项含义说明,别名,数据类型,长度, 取值范围,取值含义,与其他数据项的逻辑关系} 数据结构描述={数据结构名,含义说明,组成:{数据项或数据结构}} 数据流描述={数据流名,说明,数据流来源,数据流去向, 组成:{数据结构},平均流量,高峰期流量} 数据存储描述={数据存储名,说明,编号,流入的数据流,流出的数据流, 组成:{数据结构},数据量,存取方式} 处理过程描述={处理过程名,说明,输入:{数据流},输出:{数据流}, 处理:{简要说明}} 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点: (1) 具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解,是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法,它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术,用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示: 2.1 第零步——初始化工程

u8数据字典

用友U8的SQL SERVER 数据库结构说明表 在帐套中的两个表,一个表是RPT_GRPDEF,存放帐套中重要的表名及相关说明;另一个是RPT_ITMDEF,存放的是主要表中的相关字段说明; TableID ETableName CTableName 1 Accessaries 成套件表 2 AccInformation 帐套参数表 3 AdjustPVouch 4 AdjustPVouchs 5 Ap_AlarmSet 单位报警分类设置表 6 Ap_BillAge 帐龄区间表 7 Ap_Cancel 核销情况表 8 Ap_CancelNo 生成自动序号 9 Ap_CloseBill 收付款结算表 10 Ap_CtrlCode 控制科目设置表 11 Ap_Detail 应收/付明细帐 12 Ap_DigSet 13 AP_DispSet 查询显示列设置表 14 Ap_InputCode 入帐科目表---------- 15 Ap_InvCode 存货科目设置表 16 Ap_Lock 操作互斥表 17 Ap_MidExch 18 Ap_MyTableSet 查询条件存储表 19 Ap_Note 票据登记簿 20 Ap_Note_Sub 票据登记簿结算表 21 Ap_SstyleCode 结算方式科目表 22 Ap_Sum 应收/付总帐表 23 Ap_Vouch 应付/收单主表 24 Ap_Vouchs 应付/收单主表的关联表 25 Ap_VouchType 单据类型表 26 Ar_BadAge 坏帐计提帐龄期间表 27 Ar_BadPara 坏帐计提参数表 28 ArrivalVouch 到货单、质检单主表*** 29 ArrivalVouchs 到货单、质检单子表*** 30 AssemVouch 组装、拆卸、形态转换单主表 31 AssemVouchs 组装、拆卸、形态转换单子表 32 Bank 本企业开户银行及帐号 33 CA_ACR 按产品产量约当分配率表 34 CA_AllMt 分配率分配方法表 35 CA_AmoCt 各项费用成本表 36 CA_AsDIF 辅助部门内部固定分配率表 37 CA_AssCW 辅助费用耗用表 38 CA_AssMP 辅助部门计划单价表 39 CA_AWPC 各项费用耗用计划表

软件配置项标识编码规则设计方案解读

软件配置项标识编码规则设计方案 刘宏 2011-9-18 Mail:lh@https://www.doczj.com/doc/8f11427972.html, 1.背景 1.1.服务外包中迁移 在服务外包中,难度较大的阶段为——服务外包的迁移工程。 服务迁移工程难度大的主要原因之一,是没有实施迁移前准备标准和迁移后的验收标准。也就是在服务成熟到何种程度——包括管理与技术成熟度,服务才能够向外包方进行迁移,以便发包方有效控制服务外包中的风险,达到服务外包的目的。 服务外包迁移前应达到的准备标准——包括管理标准与技术标准,技术标准是管理标准的基础。技术标准是在服务外包迁移中的必要条件,管理标准是服务外包迁移中的充分条件。 不同服务业务在外包迁移中,具有不同的技术标准,但是具有相同的管理标准——ISO20000规定了管理相关的内容。 因为不同的服务业务具有不同的服务技术标准要求,因此正对IT服务外包业务应根据业务的特点编制相关的技术标准要求。IT服务外包业务可以包括: ●IT系统基础平台维护服务外包 ●IT系统支撑环境维护服务外包 ●应用系统的维护服务外包 1.2.服务外包迁移标准内容 每类服务有可以分成:运营服务(一线服务)、支持性服务(二线服务)、变更性服务(三线服务)。 在IT服务外包中风险较大的是运营服务,因为运营服务一直是直接在客户的生产环境实施,一旦发生错误,有可能给客户造成无法挽回的损失。目前一般风险较大的运营服务,有客户自己承担,不进行外包。 支持性服务也是在客户生产环境实施,但是一般需要进行策划与实施结果测试。由于支

持服务具有一定的技术性,因此这种服务外包迁移前应按照技术标准要求通过验收。只有通过技术标准验收的服务才能够实施服务外包的迁移。 变更性服务是在其他环境中测试完成后,在反映到生产环境中。因此变更性服务与系统建设期的系统开发存在不同的风险。在系统建设期,可以进行充分的测试与试运行测试。在变更性服务由于工期与成本的原因,可能不能充分进行测试与试运行。 1.3.服务外包迁移中标准需求 服务外包方为了及时提供服务需要将分包方的技术成果迁移到外包方处,因此分包方向服务外包方进行服务迁移时,在服务迁移时,迁移哪些内容,迁移的内容在迁移前应到技术标准要求应进行验证与确认。若是没有达到服务外包迁移技术标准,很显然是增加服务外包迁移的风险。 在服务外包迁移实施中,需要对服务外包迁移内容结果进行验证,因此需要服务外包迁移结果验证与确认的技术标准要求。 1.4.应用软件服务迁移标准需求分析 在应用软件系统维护服务外包的迁移中,技术标准主要是针对分包方迁移给外包方的所有技术成果物。对这些成果物需要相关的技术标准要求,以便在服务外包迁移过程,分包方与外包方能够有效沟通与交接,确保服务能够连续,不因为服务外包迁移发生中断或服务水平下降。 为了确保分包方与外包方能够有效进行技术沟通,首先需要明确出工程成果物的标识标准——配置项标识编码标准。这一标准能够是双方能够正确地在配置管理库中找到所需要的配置项。 为了能够有效避免交付过程中,使用错误的成果物。就需要双方共同承认的成果物的编码规则或标准。 由此得出结论:软件配置项标识编码规则,是IT应用系统维护服务外包的技术标准中的基础。 2.方案的目的与目标 2.1.目的 通过提供一般软件配置项编码规则,为企业的软件配置项的管理提供自动化处理的解决

数据库常用数据字典

Static Data Dictionary Views In Trusted Oracle Server, each of the dictionary tables and views contains a column that indicates the label of each row in the table or view. Trusted Oracle also provides some additional dictionary tables and views, and some Oracle8 dictionary tables and views contain columns that support compatibility with Trusted Oracle applications. See your Trusted Oracle documentation for more information about Trusted Oracle dictionary tables and views. Data Dictionary Views The following is an alphabetical reference of the data dictionary views accessible to all users of an Oracle Server. Most views can be accessed by any user with the CREATE_SESSION privilege. The data dictionary views that begin with DBA_ are restricted. These views can be accessed only by users with the SELECT_ANY_TABLE privilege. This privilege is assigned to the DBA role when the system is initially installed. ALL_ALL_TABLES This view describes all of the tables (object tables and relational tables) accessible to the user. ALL_INDEXES This view contains descriptions of indexes on tables accessible to the user. To gather statistics for this view, use the SQL command ANALYZE. This view supports parallel partitioned index scans. ALL_SEQUENCES This view lists descriptions of sequences accessible to the user. ALL_TABLES This view contains descriptions of relational tables accessible to the user. To gather statistics for this view, use the SQL command ANALYZE. ALL_TRIGGERS This view lists trigger information for triggers owned by the user, triggers on tables owned by the user, or all triggers if the user has the CREATE ANY TRIGGER privilege. ALL_USERS This view contains information about all users of the database. ALL_VIEWS

《环境信息数据字典规范》(征求意见稿)编制说明

附件三: 《环境信息数据字典规范》(征求意见稿) 编制说明 《环境信息数据字典规范》编制组 二○一○年十一月

项目名称:环境信息数据字典规范 项目统一编号:1520 项目承担单位:环境保护部信息中心、北京市环境信息中心 编制组主要成员:徐富春、陈华、刘定、蒋昕、潘飞、王利强、蒲铮王丽平、刘立媛 标准所技术管理负责人:李晓倩、卢延娜 标准处项目负责人:何俊

目 录 1 项目背景 (1) 1.1 任务来源 (1) 1.2 工作过程 (1) 2 标准制(修)订的必要性分析 (1) 2.1 国家及环保主管部门的相关要求 (1) 2.2 现行环保标准存在的主要问题 (2) 3 标准编制的依据与原则 (2) 3.1 标准编制的依据 (2) 3.2 标准编制的原则 (2) 4 标准主要技术内容 (2) 4.1 标准适用范围 (2) 4.2 标准结构框架 (3) 4.3 术语和定义 (3) 4.4 一般原则 (3) 5 对实施本标准的建议 (4)

《环境信息数据字典规范》编制说明 1项目背景 1.1任务来源 (1)《环境信息数据字典规范》是环境保护部2009年科技标准计划任务之一,项目编号:1520。 (2)承担单位:环境保护部信息中心、北京市环境信息中心。 1.2工作过程 接到《环境信息数据字典规范》编制的任务后,成立了标准规范编制组,在认真学习了规范编制的背景材料和任务内容后,《环境信息数据字典规范》标准规范编制组开展了数据字典标准规范相关的深度调研工作,了解数据字典标准规范相关的国际、国内的最新研究成果,为本规范提供了借鉴标准和编制依据。 标准规范编制组多次组织内部讨论后,2010年3月5日通过了科技标准司组织的标准开题论证会,基本确定了《环境信息数据字典规范》编制的工作范围、工作方法,初步规划出了规范编制思路、技术路线、规范大纲,为进一步的规范编制工作提供了基础。 会后标准编制组根据开题论证专家意见,并查阅大量的调研资料,对环境信息数据字典分类分析,对规范进行了进一步的修改和完善,并于2010年6月30日提交标准规范初稿。 标准规范编制组对初稿进行内部讨论和修改,编制《环境信息数据字典规范》征求意见稿和编制说明。 2标准制(修)订的必要性分析 2.1国家及环保主管部门的相关要求 随着经济发展与社会进步,环境形势发生了巨变,环境问题日益得到国内外关注,如何更好地管理环境、改善环境是国际社会与各国政府面临的重大问题。在我国,污染减排工作得到了党中央和国务院的高度重视,“三大体系”建设成为污染减排工作的核心抓手。环境保护部针对污染减排“三大体系”能力建设要求,规划并实施了国控重点污染源自动监控项目建设、污染源监督性监测项目建设、环境监察执法项目建设、环境信息与统计项目建设。 国家环境信息与统计能力建设项目根据《“十一五”国家环境保护标准规划》,综合参考国家电子政务标准的总体系框架,制定了国家环境信息与统计能力建设项目标准体系框架。为保障国家环境信息与统计能力建设项目顺利实施,规范减排数据库及信息系统建设,保障环境信息系统之间标准一致,要求编制《环境信息数据字典规范》,规范环境信息数据库的数据字典编制设计,为环境信息管理、资源整合与协同共享奠定基础。 《国家环境信息化2009~2015年规划(征求意见稿)》的出台为环境信息化工作提供了强有力的指导和支撑,该规划中将环境信息资源分为环境质量监测管理信息、污染监控管理信息、生态保护管理信息、核安全与辐射管理信息、环境应急管理信息,这是对环境数据集的总体概括,是整个环保业务关注的信息资源的总揽。《HJ/T 417-2007 环境信息分类与代码》规范出台,将环境信息集按照环保业务分为环境质量信息、污染源信息等9类环境信息,这是环境信息资源与数据集建设最重要的基础,可是由于分类相对较粗,在编制数据字典规范时将进

Oracle常用数据字典表(系统表或系统视图)及查询SQL

Oracle常用数据字典表(系统表或系统视图)及查询SQL 2014年12月15日?数据库?共4187字?暂无评论?阅读861 次 文章目录 ?数据字典分类 ?dba_开头 ?user_开头 ?v$开头 ?all_开头 ?session_开头 ?index_开头 ?伪表 ?数据字典常用SQL查询 数据字典是Oracle存放有关数据库信息的地方,其用途是用来描述数据的。比如一个表的创建者信息,创建时间信息,所属表空间信息,用户访问权限信息的视图等。 数据字典系统表,保存在system表空间中。查询所有数据字典可用语句“select * from dictionary;”。 数据字典分类 数据字典主要可分为四部分: 1)内部RDBMS表:x$*,用于跟踪内部数据库信息,维持DB的正常运行。是加密命名的,不允许sysdba以外的用户直接访问,显示授权不被允许。

2)数据字典表:*$,如tab$,obj$,ts$等,用来存储表、索引、约束以及其他数据库结构的信息。 3)动态性能视图:gv$*,v$*,记录了DB运行时信息和统计数据,大部分动态性能视图被实时更新以反映DB当前状态。 4)数据字典视图:user_*、all_*、dba_*,在非Sys用户下,我们访问的都是同义词,而不是V$视图或GV视图。 数据库启动时,动态创建x$,在X$基础上创建GV$,在GV$基础上创建V$X$表-->GV$(视图)--->V$(视图)。 数据字典视图可分为静态数据字典视图和动态数据字典视图。 静态数据字典是指在用户访问数据字典时内容不会发生改变。这类数据字典主要是由表和视图组成,应该注意的是,数据字典中的表是不能直接被访问的,但是可以访问数据字典中的视图。 静态数据字典中的视图分为三类,它们分别由三个前缀够成:user_*(该用户方案对象的信息)、all_*(该用户可以访问的所有对象的信息)、dba_*(全部数据库对象的信息)。 动态数据字典是Oracle包含的一些潜在的由系统管理员如SYS维护的表和视图,由于当数据库运行的时候它们会不断进行更新,所以称它们为动态数据字典。这些视图提供了关于内存和磁盘的运行情况,所以我们只能对其进行只读访问而不能修改它们。Oracle中这些动态性能视图都是以v$开头的视图,比如v$access。 dba_开头 dba_users数据库用户信息

数据库设计规范 编码规范

数据库编码规范 目的1 为了统一公司软件开发的设计过程中关于数据库设计时的命名规范和具体工作时的编程规范,便于交流和维护,特制定此规范。 2 范围 本规范适用于全体开发人员,作用于软件项目开发的数据库设计、维护阶段。 术语3 数据库对象:在数据库软件开发中,数据库服务器端涉及的对象包括物理结构和逻? 辑结构的对象。 物理结构对象:是指设备管理元素,包括数据文件和事务日志文件的名称、大小、? 目录规划、所在的服务器计算极名称、镜像等,应该有具体的配置规划。一般对数据库服产品的概要设计阶段予以规划。务器物理设备的管理规程,在整个项目/ 逻辑结构对象:是指数据库对象的管理元素,包括数据库名称、表空间、表、字段? 域、视图、索引、触发器、存储过程、函数、数据类型、数据库安全性相关的设计、数据/ 库配置有关的设计以及数据库中其他特性处理相关的设计等。 4 设计概要 4.1 设计环境R2 ORACLE 11G a) 数据库ORACLE 11G R2 操作系统 LINUX 6以上版本,显示图形操作界面 b) MS SQL SERVER 2005 数据库企业版 SQL SERVER 2005 以上补丁和安全补丁打sp3 操作系统 WINDOWS 2008 SERVER 4.2 设计使用工具做为数据库的设计工具,要求为主要字段做详尽说明。对于PowerDesigner a) 使用尽量使用企业管理器对数据库进行设计,并且要求对表,字段编写详细的说SQL Server

明(这些将作为扩展属性存入SQL Server中) 文档,作为数据字典保存,PowerDesigner b) 通过定制wordword格式报表,并导出SQL Server PowerDesigner v10 格式。(才具有定制导出word格式报表的功能)。对于一旦在企业管理器进行数据库设计时加入扩展属性,就可以通过编写简单的工具将数据字典导出。 编写数据库建数据库、建数据库对象、初始化数据脚本文件c) 设计原则4.3 采用多数据文件a) 500MB 2GB,windowb) 禁止使用过大的数据文件,系统不超过unix系统不大于数据库中必须将索引建立在索引表空间里。c) oracle 基本信息表在建立时就分配足够的存储空间,禁止其自动扩展功能d) blob(或大文本列)和大文本字列、e) blob列要独立出一张表,此表只有id 或saf) 为每一个数据库创建独立的管理员用户,使用该用户进行设计,尽量不要使用者系统管理员身份进行数据库设计。 4.4 设计的更新 a) 在设计阶段,由数据库管理员或指定的项目组其一成员进行维护。 b) 运行阶段,由数据库管理员进行维护。 c) 如对表结构进行修改,应先在数据字典文档进行修改,最后在数据库中进行修改。如果修改的是数据库字典表,必须由数据库管理员进行。 直接连代码,如果使用PowerDesigner,禁止由PowerDesignerd) 编写更新的SQL数据库进行数据库操作(如果是更改表或者字段的说明性文字可以通过数据库管理器图形界面进行修改) e) 修改数据库要通过SQL,禁止其它方式对数据进行修改 要添加说明后保存备查修改数据库的SQLf) 命名总体原则5 设定的前缀一律用小写字母? ? 标识名称命名全部小写 整个命名的全长不得超过30个字母? ,不能使用中文和其他字符,有特别情况允许使用末尾数‘_'? 全部使用字母和下划线t_Finace1, t_Finace2... 字编号。例如: ? 命名名称来自于业务,全部采用英文单词 英文单词过长可以采用通用的缩写,尽量表达出业务的含义? 如需要两个以上的英文单词做标识名称,单词之间要用下划线‘_'? 连接 ? 名称全是由名词组成的,名词由大范围到小范围排序取名

银行业大额交易报告数据字典

银行业大额交易报告数据字典 编号标签名称字段内容类型(长度)填写规则及校验 01 RINM 报告机构名称字符型,64位 02 RICD 报告机构编码字符型,15位向反洗钱中心申请,由反洗钱中心统一分配 03 RPDT 报告生成日期数值型,8位格式为:年年年年月月日日;此报告生成日 期<=文件名中所包含的报送日期 04 CTTN 交易主体总数数值型,8位总交易主体总数>= 交易主体编号 05 CA TI seqno=””交易主体编号数值型,8位交易主体编号从1开始依次递增,直到等于 总交易主体编号 06 CTNM 客户名称/姓名字符型,64位 07 CITP 客户身份证件/证 明文件类型字符型,32位11:居民身份证或临时身份证; 12:军人或武警身份证件; 13:港澳居民往来内地身份通行证;台湾居 民来往大陆通行证或其他有效旅行证件; 14:外国公民护照; 19:其他类个人身份有效证件(若选择此 项,报告机构应对其个人证件类型做进一步 说明); 21:组织机构代码; 29:其他类机构代码(若选择此项,报告机 构应对其证件类型做进一步说明) 08 CTID 客户身份证件/证 明文件号码字符型,20位其中:身份证长度应为15位或者18位; 组织机构代码长度应为9位(如为10位则 去掉最后一位校验码前的连接符‘-’)。 09 CSNM 客户号字符型,32位一个交易主体在该报告机构内有且只有一 个编号,客户号是在报告机构内识别客户唯 一性的业务主键,即便存在不同的证件类型 和证件号码,同一客户号仍然表示同一交易 主体。 10 CTNT 客户国籍字符型,3位根据国标GB/T2659-2000世界各国和地区 名称代码填写字母 11 HTDT 大额交易发生日 期 字符型,8位年年年年月月日日 12 CRCD 大额交易特征代 码数值型, 4位0901:单笔或者当日累计人民币交易20万 元以上或者外币交易等值1万美元以上的 现金缴存、现金支取、现金结售汇、现钞兑 换、现金汇款、现金票据解付及其他形式的 现金收支。 0902:法人、其他组织和个体工商户银行账 户之间单笔或者当日累计人民币200万元 以上或者外币等值20万美元以上的款项划 转。 0903:自然人银行账户之间,以及自然人与

t6数据字典

Tag:数据库用友数据库表名参照表 1 Accessaries 成套件表 2 AccInformation 帐套参数表 3 AdjustPVouch 4 AdjustPVouchs 5 Ap_AlarmSet 单位报警分类设置表 6 Ap_BillAge 帐龄区间表 7 Ap_Cancel 核销情况表 8 Ap_CancelNo 生成自动序号 9 Ap_Cl oseBill 收付款结算表 10 Ap_CtrlCod e 控制科目设置表 11 Ap_Detail 应收/付明细帐 12 Ap_DigSet 13 AP_DispSet 查询显示列设置表 14 Ap_InputCod e 入帐科目表

15 Ap_InvCod e 存货科目设置表 16 Ap_Lock 操作互斥表 17 Ap_MidExch 18 Ap_MyTabl eSet 查询条件存储表 19 Ap_Note 票据登记簿 20 Ap_Note_Sub 票据登记簿结算表 21 Ap_Sstyl eCode 结算方式科目表 22 Ap_Sum 应收/付总帐表 23 Ap_Vouch 应付/收单主表 24 Ap_Vouchs 应付/收单主表的关联表 25 Ap_VouchType 单据类型表 26 Ar_BadAge 坏帐计提帐龄期间表 27 Ar_BadPara 坏帐计提参数表 28 ArrivalVouch 到货单、质检单主表*** 29 ArrivalVouchs 到货单、质检单子表*** 30 AssemVouch 组装、拆卸、形态转换单主表

31 AssemVouchs 组装、拆卸、形态转换单子表 32 Bank 本企业开户银行及帐号 33 CA_ACR 按产品产量约当分配率表 34 CA_AllMt 分配率分配方法表 35 CA_AmoCt 各项费用成本表 36 CA_AsDIF 辅助部门内部固定分配率表 37 CA_AssCW 辅助费用耗用表 38 CA_AssMP 辅助部门计划单价表 39 CA_AWPC 各项费用耗用计划表 40 CA_Batchmx_temp 41 CA_Batchmxhy_tmp 42 CA_Batchmxhy_tmp1 43 CA_bmmx_tmp 44 CA_CBSys 系统设置表 45 CA_ClassDef 产品类别定义 46 CA_ComPD 完工产品处理表

数据字典第1部分:编制规范(无加密)

居民电子健康档案与个人健康信息系统建设标准化指南之六 PHRS/T K021-2008 国家卫生数据字典 第1部分:编制规范 National Health Data Dictionary Part 1: Specification for drafting (本稿完成日期:2008年9月) XXXX-XX-XX发布 XXXX-XX-XX实施 卫生部卫生标准委员会 批 准

前 言 《国家卫生数据字典》分为11个部分: 第1部分:编制规范; 第2部分:元数据框架; 第3部分:数据类型; 第4部分:数据模型; 第5部分:注册和管理; 第6部分:人员类; 第7部分:内容类; 第8部分:方法类; 第9部分:环境类; 第10部分:事件类; 第11部分:目的类; 本标准将来可能增加其他部分。 本部分的附录A为规范性附录,附录B为资料性附录。 本部分由卫生部卫生信息标准专业委员会提出。 本部分由卫生部统计信息中心归口。 本部分起草单位:中国人民解放军总后勤部第四军医大学卫生信息研究所本部分主要起草人:徐勇勇、王才有、刘丹红、胡建平、潘峰、王霞、杨鹏

国家卫生数据字典 第1部分:编制规范 1范围 本部分规定了国家卫生数据字典的编制原则,数据元描述的内容和详细要求,数据元分类、命名和标识规则。 本部分适用于国家卫生数据字典的编制。 2 引用文件 下列文件中的有关条款通过引用而成为部分的条款。凡注日期或版次的引用文件,其后的任何修改单(不包括勘误的内容)或修订版本都不适用于本部分。但提倡使用本部分的各方探讨使用其最新版式本的可能性。凡不注日期、分册或版次的引用文件,其最新版本适用于本部分。 ISO/IEC 11179:Information technology-Medada Registries(MDR) GB/T 18391:信息技术数据元的规范与标准化 GJB/T 6595.1-2008:后勤保障数据元字典第1部分:编制规范 3术语和定义 3.1数据data 对事实、概念或指令的一种形式化表示,适用于以人工或自动方式进行通信、解释或 处理。 [GB/T 18391.1-2002, 定义3.12] 3.2数据元 data element 用一组属性描述其定义、标识、表示和允许值的基本数据单元。 [GB/T 18391.1-2002, 定义3.14] 3.3通配数据元generic data element 可再利用的值域。 [GB/T 18391.1-2002, 图1.1] 3.4 数据字典 data dictionary 涉及其他数据应用和结构的数据的数据库,即用于存储元数据的数据库[ANSI X3.172-1990]。 [GB/T 18391.1-2002, 定义3.13] 3.5 数据元字典 data element dictionary

数据库设计规范

数据库设计规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求),在概念设计阶段形成独立于机器特点、独立于各个dbms产品的概念模式(信息世界模型),用e-r图来描述。在逻辑设计阶段将e-r图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(view)形成数据的外模式。在物理设计阶段根据dbms特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1. 需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(structured analysis,简称sa方法)从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(data dictionary,简称dd)来描述。 数据字典是各类数据描述的集合,它是关于数据库中数据的描述,即元数据,而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述={数据项名,数据项含义说明,别名,数据类型,长度, 取值范围,取值含义,与其他数据项的逻辑关系} 数据结构描述={数据结构名,含义说明,组成:{数据项或数据结构}} 数据流描述={数据流名,说明,数据流来源,数据流去向, 组成:{数据结构},平均流量,高峰期流量} 数据存储描述={数据存储名,说明,编号,流入的数据流,流出的数据流, 组成:{数据结构},数据量,存取方式} 处理过程描述={处理过程名,说明,输入:{数据流},输出:{数据流}, 处理:{简要说明}}

oracle 基本配置与数据字典-入门

oracle: 三个配置文件listener.ora、sqlnet.ora、tnsnames.ora ,都是放在$ORACLE_HOME\network\admin目录下 ref: https://www.doczj.com/doc/8f11427972.html,/blog/832429 使用数据库连接时,Oracle检查本地主机中的tnsnames.ora文件以确定要连接到哪个数据库。PLSQL、TOAD等客户端工具也是根据tnsnames.ora 来解析数据库连接 login.sql SQLPLUS 启动环境配置文件,为用户设置自定义的参数 显示所有环境参数 show all define 定义自定义变量,以及编辑工具_editor https://www.doczj.com/doc/8f11427972.html,/uid-23177306-id-2531274.html SQLPLUS学习总结 这个总结很好! show parameter service_name 开启、关闭数据库 sqlplus /nolog conn / as sysdba !! 在11g,必须conn sys/pass as sysdba/sysoper 才能执行以下命令!! startup shutdown 常用命令大全: https://www.doczj.com/doc/8f11427972.html,/chinafine/articles/1755405.html oracle 配置文件init.ora dbhome_1\srvm\admin dbhome_1\dbs select sysdate from dual; pseudo columns with normal table: select a.ename, sysdate, user, current_date,systimestamp from emp a; 关于大小写:

M编码原则与数据字典参考

一、PM编码原则与数据字典参考 (一)、主要编码原则 市场经营管理 1、业主编码六位地区码+四位年份码+三位流水号由系统自动编码 例:3206002009001 说明: (1)编码由三个层级共13位数字码长。 (2)第一层次为6位数字码,采用国标地区代码。预留两位县区码。 (3)第二层次为4位数字码,采用当前年度。 (4)第三层次为3位数字码,由计算机按先后顺序产生。 2、工程编码分公司组织代码+年四位码月两位日两位+三位流水号由系统自动编码 例:WYJSZBGS20081002001(如:浙北公司2008年10月2日第一个承接的工程)说明: (1)编码由三个层级的数字、字母码组成。 (2)第一层次为8位左右的字母码,取组织机构代码。 (3)第二层次为8位数字码,分别为项目登记时的年月日组成。 (4)第三层次为3位数字码,流水号留999个空间,由计算机按先后顺序产生。 3、合同编码分公司组织代码+年四位码+月两位+日两位+三位流水号由系统自动编码 例:WYJSZBGS20081002001(如:浙北公司2008年10月2日第一个承接的工程)说明: (1)编码由三个层级的数字、字母码组成。 (2)第一层次为8位左右的字母码,取组织机构代码。 (3)第二层次为8位数字码,分别为合同登记时的年月日组成。 (4)第三层次为3位数字码,流水号留999个空间,由计算机按先后顺序产生。 4、项目编码合同编码+“-01”系统自定义 例:WYJSZBGS20081002001-01(如:浙北公司2008年10月2日第一个承接的工程的第一个项目) 说明: (1)编码分四个层级由数字、字母码组成。 (2)第一层次为8位左右的字母码,取组织机构代码。 (3)第二层次为8位数字码,分别为合同登记时的年月日组成。

相关主题
文本预览
相关文档 最新文档