数据中心能耗数据库设计

0 下载量 129 浏览量 更新于2024-06-24 收藏 570KB DOC 举报
"能耗数据库设计文档详细介绍了用于记录和管理能耗数据的数据库结构,包括不同的数据表、字段前缀以及关键字典表的设计。文档主要关注数据中心、建筑、能耗分类和分项等核心概念,旨在提供一个高效、规范的数据存储方案。" 在能耗数据库设计中,首先定义了数据表及其字段前缀的命名规范。如"T_*_**"表示数据库表,"T_DC_**"代表数据中心相关的表,"T_BD_**"是与建筑相关的表,"T_DT_**"用于存放字典数据,"T_EC_**"是能耗数据表,"T_ST_**"和"T_OV_**"以及"T_IV_**"分别代表设计安装、原始值和增量值的表。这种命名规则有助于提高代码的可读性和维护性。 接着,文档详细列出了三个基本字典表: 1. 建筑类别表(T_DT_BuildingType):用于记录不同类型的建筑,如办公、商场、宾馆饭店、文化教育等。包含建筑类别ID(BuildingTypeID,为主键且自动递增)、建筑类别名称(BuildingTypeName)和建筑类别编码(BuildingTypeCode)。编码使用单个字符,如“办公建筑”为"A",方便快速识别。 2. 能耗分类表(T_DT_EnergyType):定义了各种能耗类型,包括电、水、燃气、集中供热/冷等,并提供了能耗分类ID(EnergyTypeID,为主键且自动递增)、能耗分类名称(EnergyTypeName)和能耗分类编码(EnergyTypeCode)。编码使用两位数字,如“电”为"01",便于分类统计。 3. 能耗分项表(T_DT_EnergySubItem):进一步细化能耗分类,如照明、空调、设备运行等。每个能耗分项有其ID(EnergyItemID,为主键且自动递增)、分项名称(EnergyItemName)和描述(Description),帮助更精确地追踪和分析能耗来源。 这些字典表为后续的能耗数据记录和分析奠定了基础,能够支持多种能耗类型和分项的查询、统计和报表生成。例如,通过建筑类别表可以了解某一类型建筑的能耗特性;通过能耗分类表可以计算不同能源的消耗总量;而能耗分项表则有助于深入挖掘能源使用的具体环节,从而提出节能措施。 设计这样的数据库结构对于监控和管理IT设施、公共建筑或大型企业园区的能耗情况至关重要。它可以支持实时监测、历史数据分析,以及制定节能策略。同时,这种设计还考虑到了扩展性和灵活性,可以适应未来可能出现的新能耗类型或分项,保证了系统的持久性和适应性。
2023-01-08 上传
能耗数据库设计 1 数据表及字段前缀说明 T_*_**:T-Table(数据库表) F-Field(数据表字段) T_DC_**:DC-Data Center(数据中心) T_BD_**:BD-Building(建筑) T_DT_**:DT-Dictionary(字典) T_EC_**:EC-Energy Consumption(能耗) T_ST_**:ST-Setting(设计安装) T_OV_**:OV-Original Value(原始值) T_IV_**:IV-Increase Value(增量值) 2 基本字典 1 建筑类别表T_DT_BuildingType "序号"字段名 "推荐数据类型"NULL及"字段中文名 "描述 " " " " "默认值" " " " "BuildingTypeID "Int " "建筑类别ID "主键, IDENTITY(1,1) " " "BuildingTypeName "Varchar(30) " "建筑类别 " " " "BuildingTypeCode "Char(1) " "建筑类别编码"办公建筑 A " " " " " " "商场建筑 B " " " " " " "宾馆饭店建筑C " " " " " " "文化教育建筑D " " " " " " "医疗卫生建筑E " " " " " " "体育建筑 F " " " " " " "综合建筑 G " " " " " " "其它建筑 H " 2 能耗分类表T_DT_EnergyType "序号 "字段名 "推荐数据类型"NULL及"字段中文名 "描述 " " " " "默认值" " " " "EnergyTypeID "Int " "能耗分类ID "主键, IDENTITY(1,1) " " "EnergyTypeName "Varchar(30) " "能耗分类 " " " "EnergyTypeCode "Char(2) " "能耗分类编码"电 01 " " " " " " "水 02 " " " " " " "燃气(天然气或煤气)03" " " " " " "集中供热量 04 " " " " " " "集中供冷量 05 " " " " " " "其它能源 06 " " " " " " "煤 07 " " " " " " "液化石油气 08 " " " " " " "人工煤气 09 " " " " " " "汽油 10 " " " " " " "煤油 11 " " " " " " "柴油 12 " " " " " " "可再生能源 13 " 3 能耗分项表T_DT_EnergySubItem "序号"字段名 "推荐数据类型"NULL及"字段中文名 "描述 " " " " "默认值" " " " "EnergyItemID "Int " "能耗分项ID "主键, IDENTITY(1,1) " " "EnergyItemName "Varchar(30) " "能耗分项 " " " "EnergyItemClass "Int " "能耗分项等级 "0:分项 " " " " " " "1:一级子项 " " " " " " "2:二级子项 " " "ItemParentID "Int " "上级能耗分项I" " " " " " "D " " " "EnergyItemCode "Char(1) " "能耗分项编码 " " " "EnergyTypeCode "Char(2) " "所属能耗分类 "目前只考虑电能分项和子" " " " " "编码 "项 " 电能分项: "分项能耗 "编码 " "照明插座用电 "A " "空调用电 "B " "动力用电 "C " "特殊用电 "D " 一级子项: "分项能耗 "分项能耗编码 "一级子项 "一级子项编码 " "照明插座用电 "A "照明与插座 "1 " " " "走廊与应急 "2 " " " "室外景观照明 "3 " "空调用电 "B "冷热站 "1 " " " "空调末端 "2 " "动力用电 "C "电梯 "1 " " " "水泵 "2 " " " "通风机 "3 " "特殊用电 "D "信息中心 "1 " " " "洗衣房 "2 " " " "厨房餐厅 "3 " " " "游泳池 "4 " " " "健身房 "5 " " " "其它 "6 " 冷热站二级子项: "二级子项 "二级子项编码 " "冷冻泵 "A " "冷却泵 "B " "冷机 "C " "冷塔 "D " "热水循环泵 "E " "电锅炉 "F " 4 仪表类型信息表T_DT_MeterType "序 "字段名 "主、外"字段中文名 "推荐数据类型"描述 " "号 " "键 " " " " " "MeterTypeCode
2023-01-08 上传
为什么需要设计数据库 这里我们思考两个问题: 修建茅屋需要设计吗?修建大厦需要设计吗? 结论是:当数据库比较复杂(如数据量大,表较多,业务关系复杂)时,我们需要先 设计数据库; 因为,良好的数据库设计能够: q 节省数据的存储空间 q 能够保证数据的完整性 q 方便进行数据库应用系统的开发 糟糕的数据库设计: q 数据冗余、存储空间浪费 q 内存空间浪费 q 数据更新和插入的异常 软件项目开发周期 我们再来看看软件项目的开发周期: 需求分析阶段:分析客户的业务和数据处理需求; 概要设计阶段:设计数据库的E-R模型图,确认需求信息的正确和完整; 详细设计阶段:将E- R图转换为多张表,进行逻辑设计,并应用数据库设计的三大范式进行审核; 代码编写阶段:选择具体数据库进行物理实现,并编写代码实现前端应用; 软件测试阶段:…… 安装部署:…… 设计数据库 在需求分析阶段,设计数据库的一般步骤为: – 收集信息 – 标识对象 – 标识每个对象的属性 – 标识对象之间的关系 在概要设计阶段和详细设计阶段,设计数据库的步骤为: – 绘制E-R图 – 将E-R图转换为表格 – 应用三大范式规范化表格 下面我们以一个BBS简易论坛的数据库设计为例来看看设计数据库的步骤: 收集信息: 与该系统有关人员进行交流、坐谈,充分理解数据库需要完成的任务 BBS论坛的基本功能: l 用户注册和登录,后台数据库需要存放用户的注册信息和在线状态信息; l 用户发贴,后台数据库需要存放贴子相关信息,如贴子内容、标题等; l 论坛版块管理:后台数据库需要存放各个版块信息,如版主、版块名称、贴子数等; 标识对象(实体-Entity) 标识数据库要管理的关键对象或实体 实体一般是名词: l 用户:论坛普通用户、各版块的版主。 l 用户发的主贴 l 用户发的跟贴(回贴) l 版块:论坛的各个版块信息 标识每个实体的属性(Attribute) 标识对象之间的关系(Relationship) l 跟贴和主贴有主从关系:我们需要在跟贴对象中表明它是谁的跟贴; l 版块和用户有关系:从用户对象中可以根据版块对象查出对应的版主用户的情况; l 主贴和版块有主从关系:需要表明发贴是属于哪个版块的; l 跟贴和版块有主从关系:需要表明跟贴是属于哪个版块的; 绘制E-R图 将E-R图转化为表格 将各实体转换为对应的表,将各属性转换为各表对应的列 标识每个表的主键列,需要注意的是:没有主键的表添加ID编号列,它没有实际含 义,用于做主键或外键,例如用户表中的"UID"列,版块表中添加"SID"列,发 贴表和跟贴表中的"TID"列 在表之间建立主外键,体现实体之间的映射关系 这里我们绘制ER图可以使用微软的Word或VISIO以及Sybase公司的PowerDesigner,它 主要用于和客户沟通交流意见,并反复修改,直到客户确认。客户确认后,再将E- R图转换为表。上面我们已经做好了这个工作。那接下来就是最后一步:应用三大范式对 设计的多张表进行审核并规范化表的结构。 数据规范化 仅有好的RDBMS并不足以避免数据冗余,必须在数据库的设计中创建好的表结构。表设 计后,很可能结构不合理,出现数据重复保存,简称数据的冗余,这对数据的增删 改查带来很多后患,所以我们需要审核是否合理,就像施工图设计后,还需要其他 机构进行审核图纸是否设计合理一样。 如何审核呢?需要一些有关数据库设计的理论指导规则,这些规则业界简称数据库的 范式。Dr E.F.codd 最初定义了规范化的三个级别,范式是具有最小冗余的表结构。这些范式是: – 第一范式(1st NF -First Normal Fromate) – 第二范式(2nd NF-Second Normal Fromate) – 第三范式(3rd NF- Third Normal Fromate) 如果每列都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式 (1NF)。第一范式的目标是确保每列的原子性。 如果一个关系满足1NF,并且除了主键以外的其他列,都依赖于该主键,则满足第二范 式(2NF)。第二范式要求每个表只描述一件事情,确保表中的每列,都和主键相 关。 如果一个关系满足2NF,并且除了主键以外的其他列都不传递依赖于主键列,则满足第 三范式(3NF)。第三范式确保每列都和主键列直接相关,而不是间接相关。 下面我们来看个形象的例子吧!假设某建筑公司要设计一个数据库。公司的业务规则 概括说明如下: 公司承担多个工程项目,每一项工程有:工程号、工程名称、施工人员等 公司有多名职工,每一名职工有:职工号、姓名、性别、职务(工程师、技术员)等 公司按照工时和小时工资率支付工资,小时工资率由职工的职务决定(例如,技术员 的小时工资率与工程师不