商业地产数据库设计方案

版权申诉
0 下载量 36 浏览量 更新于2024-07-02 收藏 682KB DOCX 举报
商业地产数据库设计是构建商业地产相关业务系统的关键部分,它涉及到存储、管理和检索商业地产领域的各种数据。以下是对给定文件中涉及的主要表格和字段的详细解释: 1) 用户表(Users) - 用户编号(UserID):作为主键,标识每个用户的唯一身份,通常自动增长。 - 用户名(Username):用于登录的用户名,通常不允许为空,确保用户账户的唯一性。 - 密码(Password):加密后的用户密码,用于验证用户身份。 - 密码提示问题(PwdQuestion)和答案(PwdAnswer):提供密码重置功能。 - 加入日期(JoinDate):记录用户注册时的时间。 - 最后登录日期(LastLoginDate)和时间(LoginTime):跟踪用户最近一次登录的时间。 - 登录状态(LoginStatus):表示用户当前是否在线,0表示未登录,1表示已登录。 - 登录IP(LoginIP):记录用户登录时的IP地址,可用于安全监控。 - 广告图片(AdverPicture):可能用于显示用户的广告或头像。 - VIPUrl:可能指向用户的VIP页面或特殊权限链接。 - 用户类型(UserType)和业主类型ID(OwnerTypeId):区分用户的不同角色或权限等级。 - 用户等级(UserLevel):表示用户在系统中的级别,如普通会员、高级会员等。 - 用户积分(UserScore):衡量用户活跃度或贡献度的数值。 - 审核状态(IsChecked):0表示未审核,1表示已审核,2表示挂停,用于管理用户信息的合法性。 - 审核日期(CheckDate)和审核员(Checker):记录审核信息。 - 删除状态(DeleteFlag):0表示未删除,1表示已删除,用于数据清理和恢复。 2) 用户信息表(UserInfo) - UID:与用户表的用户编号关联,作为外键,确保用户信息与用户账户的一致性。 - 真实姓名、性别、省、市、区、地址、联系人、公司名称、店铺名称、电话:这些字段提供了用户的个人信息和商业信息。 - 公司LOGO、营业执照、其他证件:存储公司的视觉标识和其他相关证明文件。 - 公司备注(CompanyRemark)、业务范围(BusRange):描述公司业务和额外信息。 3) 会员记录 - Id:会员记录的主键,自动增长,标识会员订阅的唯一记录。 - UID:用户编号,与用户表关联,表示哪个用户的会员记录。 - 开始日期(StartDate)和结束日期(EndDate):定义会员资格的有效时间。 - 会员套餐(Package):标识用户选择的会员等级或服务包。 - 是否启用(IsEnabled):标记会员记录是否有效,可能用于暂停或恢复会员权益。 - 备注(Remark):记录关于会员记录的附加信息。 4) 成功案例(SuccessCase) - 案例编号(CaseId):主键,自增,每个成功案例的唯一标识。 - 公司编号(CompanyId):与用户信息表中的UID关联,表明案例所属的公司。 - 案例名称:简要描述成功案例的主题。 - 案例详情(CaseDetails):可能包含更全面的案例介绍、成果展示等。 这个数据库设计涵盖了商业地产领域用户管理、会员服务、公司信息和成功案例展示等多个方面,为商业地产平台提供了全面的数据支撑。通过这样的设计,可以高效地存储、查询和分析商业地产相关的数据,支持业务运营、用户管理、市场分析等功能。
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)。第三范式确保每列都和主键列直接相关,而不是间接相关。 下面我们来看个形象的例子吧!假设某建筑公司要设计一个数据库。公司的业务规则 概括说明如下: 公司承担多个工程项目,每一项工程有:工程号、工程名称、施工人员等 公司有多名职工,每一名职工有:职工号、姓名、性别、职务(工程师、技术员)等 公司按照工时和小时工资率支付工资,小时工资率由职工的职务决定(例如,技术员 的小时工资率与工程师不