DBMS里的一些"自圆其说"

本文探讨了数据库设计中ForeignKey与References的概念及其应用。通过具体案例,分析了User与BillingDetails两个表之间的关联,并讨论了不同设计方案的优劣。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

DBMS里的一些"自圆其说"

再次看Hibernate时,发现自己又一次地让SQL里的"foreign key"和"References"这个两个关键字给缠上了.

<JavaPersistenceWithHiberante>这本书在讲"Object-oriented domain model"和"peresistent relational"间的不匹配时有这样一个例子:

假设要设计一个网上电子商务的系统,有两个很基本的类来描述那些基本信息:User和BillingDetails.

如下是这两个类的属性:

    public class User{
        private String username;
        private String name;
        private String address;
        private Set billingDetails;

        //.....
    }    

    public class BillingDetails{
        private String accountNumber;
        private String accountName;
        private String accountType;
        pirvate User user;

        //........
    }

建表时的Schema是这样的:
    create table USERS(
        USERNAME varchar(15) not null primary key,
        NAME varchar(50) not null,
        ADDRESS varchar(100)
    )

    create table BILLING_DETAILS (
        ACCOUNT_NUMBER varchar(10) not null primary key,
        ACCOUNT_NAME varchar(50) not null,
        ACCOUNT_TYPE varchar (2) not null,
        USERNAME varchar(15) foreign key references user
    )

这些与Hibernate根本没什么关系,说到底一些理解上的不足是自己的数据库知识不扎实.

由于没有自己设计数据库应用的经验,对这两个表间的关联关系设计成这样是可以理解,但经类似"为什么不那样呢?"的提问后就把自己陷进一个泥滩了:
    1,关于"foreign key"的理解:为什么叫"foreign key"呢?是什么特征让它成foreign了,不被看成"自己人"?对此我有两种"自圆其说",(1)BILLING_DETAILS表中的这个USERNAME实际上是USERS表安插到BILLING_DETAILS表里的一个"卧底",通过这种"卧底"的方式,DATABASE MANAGEMENT SYSTEM就可以有效地监测并"上报"BILLING_DETAILS表中的USERNAME是否有越USERS表中所列USERNAME之轨的行为.也就是说BILLING_DETAILS中的USERNAME必须是USERS中USERNAME的子集,而这种子集的表现与保证DBMS是通过"foreign key"来实现的.(2)第二种"解释"就太牵强,也有些搞笑了,由于BILLING_DETAILS表中已有ACCOUNT_NUMBER来当"primary key"了,那能容忍你一个外来的"USERNAME"当什么key呀?强龙压不过地头蛇嘛,不过为了照顾各方面的关系就安排你来作为了个"foreign key"吧.

    经过上面的"自圆其说"后,现在心里亮堂些了:DBMS通过"primary key"来保证表内数据(也就是记录间)Integrity,而表间的Integrity是以"foreign key"的形式来保证的.

    现在"foreign key"的问题解决后,references的问题就迎刃而解了.

    2,下一个话题:那为什么不在USERS表里建"foreign key references"来替换现在的样式而达到表间数据Integrity的效果呢?没法建?可以通过添加ID方式来实现呀.

    通过下面的方式不就实现了吗?
    create table USERS(
        USER_ID int not null primary key,
        USERNAME varchar(15) not null,
        NAME varchar(50) not null,
        ADDRESS varchar(100),
        BILLING_DETAILS_ID foreign key references BILLING_DETAILS
    )

    create table BILLING_DETAILS (
        BILLING_DETAILS_ID int not null primary key,
        ACCOUNT_NUMBER varchar(10) not null,
        ACCOUNT_NAME varchar(50) not null,
        ACCOUNT_TYPE varchar (2) not null        
    )
    (呵呵,干的漂亮!我看你怎么解释?)
    这个怎么来"自圆其说"呢?这个嘛.................还是且听下回分说吧.
    

   
基于MATLAB的建筑能耗建模系统含源码+设计报告(高分毕设项目).zip 主要功能 建立建筑物能源系统的数学模型,包括锅炉、管道、散热器、混合器、空调机组等多种元件 使用隐式求解方法解决系统的能量平衡方程 支持多个求解器并行计算不同水循环系统 提供了连接不同求解器的Bridge类 项目目标**:建立一个可配置的建筑能耗模型,模拟住宅或商用建筑在不同气候条件下的热能耗与用电动态,支持节能控制策略模拟。 应用背景 随着建筑能耗在全球总能耗中的占比不断提高,利用数学建模和计算机仿真技术对建筑热环境进行预测与优化显得尤为重要。该项目通过 MATLAB 平台构建简洁、可扩展的建筑能耗仿真环境,可用于研究: * 建筑围护结构对能耗的影响 * 加热、通风和空调系统(HVAC)策略优化 * 被动/主动节能控制策略 * 与外部天气数据的交互仿真(如 TMY3) 核心模型类(.m 文件): AirHeatExchanger.m, Boiler.m, Chiller.m, Pipe.m, Radiator.m, FanCoil.m, HeatExchanger.m, Mixer.m, Same.m 这些文件定义了热交换器、锅炉、冷水机组、管道、散热器、风机盘管、混合器等建筑能源系统组件的数学模型及热平衡方程。 控制与求解相关: SetpointController.m:HVAC 设置点控制器。 Solver.m:核心数值求解器,用于建立并求解系统线性方程组。 系统集成与桥接: Bridge.m:用于连接多个 solver 或不同流体系统之间的耦合关系。 Constant.m:定义恒定温度源或引用变量。 环境与区域: Zone.m:建筑空间(房间)模块,模拟热容、传热等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值