能耗数据库设计详解:架构与分类

1 下载量 37 浏览量 更新于2024-06-23 收藏 570KB DOC 举报
能耗数据库设计是一个关键的IT项目,旨在构建一个结构化的数据存储系统来管理建筑物和数据中心的能耗数据。该数据库设计包含多个核心表,每个表都代表了数据的不同方面,以确保信息的有效组织和分析。 1. 数据表与字段前缀: - T_**: 表示表格(Table),用于标识数据库中的各个实体。 - F_**: 表示字段(Field),用来描述数据表中的具体属性。 主要表包括: - T_DC_**: 数据中心(DataCenter)表,用于记录数据中心的基本信息,如ID、名称等。 - T_BD_**: 建筑(Building)表,记录建筑物的详细数据,包括类别、编码等。 - T_DT_**: 字典(Dictionary)表,用于存储分类和子项目的定义,例如建筑类别表(T_DT_BuildingType)和能耗分类表(T_DT_EnergyType)。 - T_EC_**: 能耗(EnergyConsumption)表,追踪具体的能耗数据,如能耗类型、分项等。 - T_ST_**: 设计安装(Setting)表,可能涉及设备设置或安装参数信息。 - T_OV_**: 原始值(OriginalValue)表,保存初始状态的数据。 - T_IV_**: 增量值(IncreaseValue)表,记录数据的变化情况。 2. 基本字典表: - **T_DT_BuildingType**: 包含了不同类型的建筑,如办公、商场、宾馆饭店等,通过BuildingTypeID作为主键,保证唯一性。 - **T_DT_EnergyType**: 详细列出各种能源类型,如电、水、燃气、集中供热量等,每种类型都有一个唯一的EnergyTypeID。 3. 能耗分项表(T_DT_EnergySubItem): 这个表详细列举了能耗的子项目,如电力消耗的各个部分,通过EnergyItemID作为主键。这样的设计有助于细致地跟踪和分析能耗数据。 在设计过程中,这些表格的关联性和数据完整性至关重要。通过这些表格,我们可以建立一套全面的能耗管理系统,不仅便于数据的输入、查询和更新,还能支持数据分析和报告生成,帮助决策者做出更科学的节能减排措施。此外,数据库设计时还需要考虑性能优化、数据安全以及数据备份等问题,以确保系统的稳定运行和长期维护。
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)。第三范式确保每列都和主键列直接相关,而不是间接相关。 下面我们来看个形象的例子吧!假设某建筑公司要设计一个数据库。公司的业务规则 概括说明如下: 公司承担多个工程项目,每一项工程有:工程号、工程名称、施工人员等 公司有多名职工,每一名职工有:职工号、姓名、性别、职务(工程师、技术员)等 公司按照工时和小时工资率支付工资,小时工资率由职工的职务决定(例如,技术员 的小时工资率与工程师不