一对多的自身关联
一的一方和多的一方都属于同一个类
这种结构就类似于树状结构
每一个对象内部本身包括
一个父节点对象(此时这个原本的对象对于这个父节点对象是多对一的关系)
一个子节点的集合(此时这个对象对于子节点集合来说又是一对多的关系）
创建表
create table creature(
id bigint primary key,
name varchar(15),
parent_creature_id bigint
);
一对一关联第一种关联方式通过一个表的主键由另一个表来产生
第一张表
create table husband(
id varchar(100) primary key,
name varchar(100) default ''
)character set utf8 collate
utf8_general_ci;---能插入中文字符
create table wife(
id varchar(100) primary key,
name varchar(100) default ''
)character set utf8 collate utf8_general_ci;
Husband.hbm中uuid方式产生主键
在wife hbm中
husband
Hibernate: insert into husband (name, id) values (?, ?)
Hibernate: insert into wife (name, id) values (?, ?)
public class Test_Normal {
public static void saveTeacherWithCascade() throws Exception{ Session session = HibernateUtil.currentSession();
Transaction tx = null;
try{
tx = session.beginTransaction();
Creature creator = new Creature("creator");
Creature fly = new Creature("fly");
Creature bird = new Creature("bird");
Creature dragon = new Creature("dragon");
bird.setParentCreature(fly);
fly.getChildCreatureSet().add(bird);
dragon.setParentCreature(fly);
fly.getChildCreatureSet().add(dragon);
fly.setParentCreature(creator);
creator.getChildCreatureSet().add(fly);
session.save(creator);
https://www.doczj.com/doc/4418022504.html,mit();
}catch(Exception e){
e.printStackTrace();
if(tx != null){
tx.rollback();
}
}finally{
session.close();
}
}
public static void main(String[] args)throws Exception { saveTeacherWithCascade();
}
}
目录 一Codd的RDBMS12法则——RDBMS的起源 二关系型数据库设计阶段 三设计原则 四命名规则 数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。 从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。 一 Codd的RDBMS12法则——RDBMS的起源 Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。 1. 信息法则关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2. 保证访问法则依靠表名、主键值和列名的组合，保证能访问每个数据项。 3. 空值的系统化处理支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。 4. 基于关系模型的动态联机目录数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样 的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用 户可以访问的表中。 5. 统一的数据子语言法则一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少 有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规 则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL) 6. 视图更新法则所有理论上可以更新的视图也可以由系统更新。 7. 高级的插入、更新和删除操作把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应 于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视 作集合。 8. 数据的物理独立性不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都 保持着逻辑上的不变性。 9. 数据的逻辑独立性当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑 上的不变性。 10. 数据完整性的独立性专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
经典表关联与多表查询 目的： 1.掌握从多个表查询数据的基本知识 2.了解和学习外连接(out join) 3.掌握内连接 授课内容： 1.对多于一个表的数据查询 1.1现实情况中，在数据库应用中，数据存在于多个相关联的表中。基本上没有数据只 存在于一个表中的情况。小的应用系统一般也有十几个表，大型系统一般有上千个表。 1.2你经常要作的就是在多个表中进行数据查询。 1.3Oracle对多表查询使用表连接的技术（table join） 1.4表连接的基本条件： (1)2个表必须有公共字段（同名字段或不同名字段） (2)在一个表中，这个公共字段必须是主键（PK） 1.5二个表中的公共字段，在一个表中是主键，在另外一个表中就是外键(FK)。 1.6二表关联中，公共字段是主键的表称为父表（主表）。是外键的表称为子表（详细 表）。 1.7研究一下scott下的emp和dept表的关系。 1.8研究一下oe下的表： CATEGORIES_TAB CUSTOMERS INVENTORIES ORDERS ORDER_ITEMS PRODUCT_DESCRIPTIONS PRODUCT_INFORMATION 1.9多表查询的语法 select 子句 from 表1[ 别名]，表2[ 别名]，视图[ 别名]，（select 子句）别名 where 连接语句 and 其他条件语句 [oupy by 分类项目] [having 子句] [order by 子句] 1.10任务：查询每个员工的编号，姓名，部门名称，部门位置 select empno,ename, dname,loc from emp a,dept b where=
数据库表关系模型解析6——多对多 狼奔代码生成器是一款为程序员设计的前期开发辅助工具，是一个软件项目智能开发的平台，它可以自动生成https://www.doczj.com/doc/4418022504.html,页面及后台代码。 实践开发过程中，我们使用PowerDesigner设计数据库模型。狼奔代码生成器就是读取PowerDesigner设计的数据库模型，分析其中的表与表之间的关系模型，分析其中的表和字段的说明信息中的关键字，自动生成不同的页面。 表与表之间的关系模型包括 1.单表数据模型 2.自连接数据模型 3.一对一数据模型 4.一对多数据模型 5.一对多数据模型中的一张表是自连接 6.多对多数据模型 7.多对多数据模型中的一张表是自连接 关键字包括 1.查询 2.状态 3.上传 4.工作流
架构图 数据访问层(DAL) 数据实体Entity Framework 业务实体和校验元数据 业务逻辑层(BLL) 业务处理 工作流 事务 接口层(IBLL)服务契约 展示层（App ）View （视图） Controller （控制器） Models （页面实体）对其他系统暴露服务Service （服务） 公共组件 安全组件 日志记录 异常捕获 公共类库(Common) 组件说明
图表1项目组件说明图 1)App——页面展示层 采用MVC框架，使用Jquery脚本库，控件选用Easyui。 2)WcfHost——服务宿主(后期扩展) 为对外的服务提供宿主，使用WCF技术，HTTPS通讯协议。 3)IBLL——业务接口层 业务逻辑层的方法对外暴露的接口和服务契约。 4)BLL——业务逻辑层 业务逻辑的操作，包括业务处理，事务，日志。 5)DAL——数据访问层 数据库访问的操作，数据实体，业务实体，数据校验，使用Entity Framework。6)Common——公共组件层 整个应用程序使用的公共辅助方法。 7)WFActivitys——工作流活动层(后期扩展) 定义了工作流需要的活动，使用微软WF技术。 8)WFDesigner——工作流设计器(后期扩展) 可以让实施人员自由配置工作流的设计器，使用微软WPF技术。 采购计划明细和分发的作用 业务需求：将采购计划明细中的物资分发到不同的站点 采购计划明细和分发之间有一张关联表，这三张表就构成了一个典型的“多对多数据模型” 下面我们以分发为例子分析“多对多数据模型”数据模型，代码已在生成的文件中，并且注释详备，此文不再赘述 数据模型 采购计划明细和分发之间是多对多的关系
数据库建表-- 一对多/多对一/一对一/多对多关系 关联映射：一对多/多对一存在最普遍的映射关系，简单来讲就如球员与球队的关系；一对多：从球队角度来说一个球队拥有多个球员即为一对多多对一：从球员角度来说多个球员属于一个球队即为多对一数据表间一对多关系如下图： 关联映射：一对一关系就如球队与球队所在地址之间的关系，一支球队仅有一个地址，而一个地址区也仅有一支球队。数据表间一对一关系的表现有两种，一种是外键关联，一种是主键关联。图示如下： 一对一外键关联： 一对一主键关联：要求两个表的主键必须完全一致，通过两个表的主键建立关联关系 关联映射：多对多 多对多关系也很常见，例如学生与选修课之间的关系，一个学生可以选择多门选修课，而每个选修课又可以被多名学生选择。数据库中的多对多关联关系一般需采用中间表的方式处理，将多对多转化为两个一对多。 数据表间多对多关系如下图：
---------------------------------------------------------------------------------------------------------- 前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者 select * from 主表where id in (select 主表id from 关系表) 1，角色任命型 特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。 界面特点：显示主表，用checkbox或多选select设置多选关系。 例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。 增加关系：如果没有组合纪录，insert之。 删除关系：如果有组合纪录，删除之。 2，集合分组型 特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。 界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。 例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表） 增加关系：同版主任命型。 删除关系：同版主任命型。 3，明细帐型
系统名称：客户关系管理系统 一、系统需求分析： 客户管理系统是为了方便管理客户基本信息，完成公司决策的重要手段， 通过该系统， 系统管理员可以通过次系统查询客户的基本信息，以及客户所购产品的信息。并可以对新老客户进行添加和删除，也可对现有用户的基本信息进行更改。从而实现公司对其客户的管理。 客户可以通过该数据库查看自己的基本信息和消费情况。 职员可以通过该数据库查看自己的基本情况、业绩情况和工作计划。 该数据库包含5个实体，分别是客户，联系人，产品，任务计划，反馈信息。 通过该数据库，可以实现以下功能（举例） 简单查询： ①查询客户的基本信息 ②查询公司职员的业绩情况（即联系人发展的客户情况） ③查询公司职员的任务计划 复杂查询： ①查询客户对某一类型产品的反馈信息（通过产品表和反馈信息表连接实现） ②查询客户反馈信息的受理情况 插入功能： 增添新客户，新产品，新联系人，新反馈信息以及其相关属性 修改功能： 系统管理员修改客户的基本信息（如积分，联系方式等），修改联系人的工作计划，反馈信息的受理情况 二、E-R图
三、关系模式 系统中的实体有：客户，联系人，反馈信息，任务计划，产品 关系模式如下： 客户（客户编号，姓名，联系方式，联系地址，积分，信用度，所购产品，消费时间，联系人编号） 联系人（联系人编号，姓名，所属部门，产品类型，任务计划编号，工资） 反馈信息（反馈编号，反馈人姓名，反馈时间，反馈内容，产品编号，解决情况）任务计划（任务计划编号，联系人编号，客户数量，计划利润，计划时间，实施情况）产品（产品编号，产品名称，生产日期，产品类型，质量级别，价格，优惠情况）反馈（客户编号，反馈编号） 发展（联系人编号，客户编号） 购买（客户编号，产品编号，购买时间，购买数量） 制定（联系人编号，任务计划编号，制定时间） 四，物理设计
一条Update更新语句是不能更新多张表的，除非使用触发器隐含更新。而表的更新操作中，在很多情况下需要在表达式中引用要更新的表以外的数据。我们先来讨论根据其他表数据更新你要更新的表 一、MS SQL Server 多表关联更新 sql server提供了update的from 子句，可以将要更新的表与其它的数据源连接起来。虽然只能对一个表进行更新，但是通过将要更新的表与其它的数据源连接起来，就可以在update的表达式中引用要更新的表以外的其它数据。 一般形式： update A SET 字段1=B表字段表达式, 字段2=B表字段表达式 from B WHERE 逻辑表达式 例如： UPDATE dbo.Table2 SET dbo.Table2.ColB = dbo.Table2.ColB + dbo.Table1.ColB FROM dbo.Table2 INNER JOIN dbo.Table1 ON (dbo.Table2.ColA = dbo.Table1.ColA); 实际更新的操作是在要更新的表上进行的，而不是在from子句所形成的新的结果集上进行的 二、Oracle 多表关联更新 Oracle没有update from语法，可以通过两种实现方式： 1、利用子查询： update A SET 字段1=（select 字段表达 式 from B WHERE ...）, 字段2=（select 字段表达式 from B WHERE ...） WHERE 逻辑表达式 UPDATE多个字段两种写法：
写法一： UPDATE table_1 a SET col_x1 = (SELECT b.col_y1, b.col_y2 FROM table_2 b WHERE b.col_n = a.col_m), col_x2= (SELECT b.col_y2 FROM table_2 b WHERE b.col_n = a.col_m) WHERE EXISTS(SELECT * FROM table_2 b WHERE b.col_n = a.col_m) 或 UPDATE table_1 a SET col_x1 = (SELECT b.col_y1, b.col_y2 FROM table_2 b WHERE b.col_n = a.col_m), col_x2= (SELECT b.col_y2 FROM table_2 b WHERE b.col_n = a.col_m) WHERE a.col_m=(SELECT b.col_n FROM table_2 b WHERE b.col_n = a.col_m) 写法二： UPDATE table_1 a SET(col_x1, col_x2)= (SELECT b.col_y1, b.col_y2 FROM table_2 b WHERE b.col_n = a.col_m) WHERE EXISTS(SELECT * FROM table_2 b WHERE b.col_n = a.col_m); 或 UPDATE table_1 a SET(col_x1, col_x2)= (SELECT b.col_y1, b.col_y2 FROM table_2 b WHERE b.col_n = a.col_m) WHERE a.col_m=(SELECT b.col_n FROM table_2 b WHERE b.col_n = a.col_m)注意： 1. 对于子查询的值只能是一个唯一值，不能是多值。 2. 子查询在绝大多数情况下，最后面的where EXISTS子句是重要的，否则将得到错误的结果。且where EXISTS子句可用另一方法代替，如上。最后的子句是对a表被更新记录的限制，如无此句，对于a表中某记录，如在b表中关
多表之间的关系操作总结 经典例子： 一对一：身份证号码与人 一对多：城市与大学，订单与订单项，部门与员工，班级与学生等等。 多对一：一对多的反面。订单项与订单，大学与城市，员工与公司，学生与班级。多对多：学生与老师 一对多：单向、双向。 一对多关系中单向与双向的区别: 单向体现在程序中就是你可以通过一方得到另一方，但不能通过另一方得到这一方双向就是彼此都能得到对方，相互都有关于对方的一个引用。（外键） 什么时候需要用单向，什么时候需要用双向。 网友答： 只需要从一方获取另一方的数据时就使用单向关联 双方都需要获取对方数据时就使用双向关系 部门---人员 使用人员时 如果只需要获取对应部门信息(user.getDeptarment()) 不需要从部门下的人员信息时，就配置成单向多对一 使用部门时 如果只需要获取部门下人员信息(deptartmanet.getUsers()) 不需要从人员获取部门信息时，就配置成单向一对多 既要获取部门下人员 deptartmanet.getUsers() 又要从人员获取部门信息 user.getDeptarment() 那就配置成双向一对多,也就是双向多一
看需求来配置了。 单向多对一”、“单向一对多，其实概念一样，记得在多的一端配置 双向一对多就是两边都要配，做到你中有我我中有你 弄清楚：关系维护端和关系被维护端。 1—m：多的一方是关系维护端，关系维护端负责外键记录的更新，关系被维护端没有权利更新外键字段。 不管是一对多，还是多对一，外键一定建在多的那方。外键一定是另一张表中已经存在的主键。 关于@mappedBy和@JoinColumn 表示声明一对多关系由对方维护，自己将不再维护，就算在自己这端设置值，保存到数据库后外键依然是null @mappedBy注解的作用：在JPA中，在@OneToMany里加入mappedBy属性可以避免生成一张中间表。 网上： a）只有OneT oOne,OneT oMany,ManyToMany上才有mappedBy属性，ManyToOne不存在该属性； b）mappedBy标签一定是定义在the owned side（被拥有方，也叫关系被维护端，即一的一方），他指向theowning side（拥有方，也叫关系维护端，即多的一方）； c）关系的拥有方负责关系的维护，在拥有方建立外键。所以用到@JoinColumn d）mappedBy跟JoinColumn/JoinTable总是处于互斥的一方，可以理解为正是由于拥有方的关联被拥有方的字段存在，拥有方才拥有了被拥有方。mappedBy这方定义JoinColumn/JoinT able总是失效的，不会建立对应的字段或者表。 @JoinColumn所在实体是关系拥有方，name的值即拥有方对应表到参考表的外键名称。@ mappedBy所在实体是关系的被拥有方，value值owner中表示被拥有类的属性。 举例子：创建两个实体类 一对多时，建立实体类时：一的一方需要一个Set或者List集合存储多的对象，多的一方需要定义一个一的对象。需要设置外键的一方需要加上@JoinColoumn注解。 例子： 城市与大学：一对多
目录 一 Codd的RDBMS12法则——RDBMS的起源 二关系型数据库设计阶段 三设计原则 四命名规则 数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。 从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。 一?Codd的RDBMS12法则——RDBMS的起源 Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。 1.信息法则?关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2.保证访问法则?依靠表名、主键值和列名的组合，保证能访问每个数据项。 3.空值的系统化处理?支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。 4.基于关系模型的动态联机目录?数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样 的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用 户可以访问的表中。 5.统一的数据子语言法则?一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少 有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规 则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL) 6.视图更新法则?所有理论上可以更新的视图也可以由系统更新。 7.高级的插入、更新和删除操作?把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应 于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视 作集合。 8.数据的物理独立性?不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都 保持着逻辑上的不变性。 9.数据的逻辑独立性?当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑 上的不变性。 10.数据完整性的独立性?专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
Sql语句多表联合查询 查询所要用到的表 1．course表 USE[学生管理] GO /****** Object: Table [dbo].[course] Script Date: 04/28/2015 11:37:12 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO SET ANSI_PADDING ON GO CREATE TABLE[dbo].[course]( [课号][nvarchar](20)NOT NULL, [课名][char](20)NOT NULL, [类型][char](10)NOT NULL, [学分][int]NOT NULL, PRIMARY KEY CLUSTERED ( [课号]ASC )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF, IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON) ON[PRIMARY] )ON[PRIMARY] GO SET ANSI_PADDING OFF GO
2.score表 USE[学生管理] GO /****** Object: Table [dbo].[score] Script Date: 04/28/2015 11:38:18 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE[dbo].[score]( [学号][nvarchar](20)NOT NULL, [课号][nvarchar](20)NOT NULL, [考试成绩][decimal](9, 2)NULL, [平时成绩][decimal](9, 2)NULL, PRIMARY KEY CLUSTERED ( [学号]ASC, [课号]ASC )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF, IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON) ON[PRIMARY] )ON[PRIMARY] GO 3.学生表 USE[学生管理] GO /****** Object: Table [dbo].[student] Script Date: 04/28/2015 11:39:09 ******/ SET ANSI_NULLS ON GO
一对多的自身关联 一的一方和多的一方都属于同一个类 这种结构就类似于树状结构 每一个对象内部本身包括 一个父节点对象(此时这个原本的对象对于这个父节点对象是多对一的关系) 一个子节点的集合(此时这个对象对于子节点集合来说又是一对多的关系） 创建表 create table creature( id bigint primary key, name varchar(15), parent_creature_id bigint ); 一对一关联第一种关联方式通过一个表的主键由另一个表来产生 第一张表 create table husband( id varchar(100) primary key,
name varchar(100) default '' )character set utf8 collate utf8_general_ci;---能插入中文字符 create table wife( id varchar(100) primary key, name varchar(100) default '' )character set utf8 collate utf8_general_ci; Husband.hbm中uuid方式产生主键
mysql 多表联合查询 Mysql多表查询，多表插入和多表更新 2010年8月27日星期四 11:24 A.M. /*************************************by garcon1986*****************************************************/ 多表查询： CREATE TABLE IF NOT EXISTS contact( contact_id int(11) NOT NULL AUTO_INCREMENT, user_name varchar(255), nom varchar(255), prenom varchar(255), mail varchar(64), passcode char(64), PRIMARY KEY(contact_id) ); CREATE TABLE IF NOT EXISTS droit( droit_id int( 11 ) NOT NULL AUTO_INCREMENT , droit varchar(255), PRIMARY KEY(droit_id) ); CREATE TABLE IF NOT EXISTS contactdroit( contactdroit_id int(11) NOT NULL AUTO_INCREMENT, contact_id int( 11 ), droit_id int( 11 ), PRIMARY KEY( contactdroit_id ) ); Insert into contact(contact_id, user_name) values(1,'user1'); Insert into contact(contact_id, user_name) values(2,'user2'); Insert into contact(contact_id, user_name) values(3,'user3'); Insert into droit(droit_id, droit) values(1,'admin'); Insert into droit(droit_id, droit) values(2,'superuser'); Insert into contactdroit(contact_id, droit_id) values(1, 1); Insert into contactdroit(contact_id, droit_id) values(2, 1); Insert into contactdroit(contact_id, droit_id) values(3, 2); SELECT c.contact_id, d.droit_id, d.droit FROM contact c, contactdroit cd, droit d where c.contact_id = cd.contact_id and cd.droit_id = d.droit_id; 结果： contact_id droit_id droit 1 1 admin 2 1 admin
例： Person表和Dept部门表 一个部门里可以有多个person 一对多的关系 多个person可以属于同一个部门多对一的关系 public class Person { private Integer id; private String name; private int sex; private String degree; private Date birthday; private int salary=10000; private Dept dept; //与Dept表的关联 } public class Dept { private Integer id; private String deptName; private Set
none: 所有情况下均不进行关联操作。这是默认值。 save-update: 在执行save/update/saveOrUpdate时进行关联操作。 delete: 在执行delete 时进行关联操作。 Dept.hbm.xml
数据库设计多对多关系的几种形态(转) 前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者select * from 主表where id in (select 主表id from 关系表) 1，角色任命型 特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。 界面特点：显示主表，用checkbox或多选select设置多选关系。 例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。 增加关系：如果没有组合纪录，insert之。 删除关系：如果有组合纪录，删除之。 2，集合分组型 特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。 界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。 例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表） 增加关系：同版主任命型。 删除关系：同版主任命型。 3，明细帐型
特点：关系表可以有重复纪录，关系表一般有时间字段，有主键，可能还有文字型的字段用来说明每次发生关系的原因（消费）。 界面特点：显示关系表，用radio或下拉设置单选关系。 例如：现金消费明细帐或订单（用户表-订单表-消费原因表），用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。 增加关系：不管有没有组合纪录，insert之，纪录时间。 删除关系：根据关系表PK删除。 4，评论回复型 特点：同明细帐型关系表一般有时间字段，有主键，区别是重点在文字型的字段用来说明每次发生关系的内容（评论回复）。 界面特点：回复文本框。 例如：论坛回复（用户表-回复表-帖子表），用户可能多次在不同帖子上评论回复费。 增加关系：不管有没有组合纪录，insert之，纪录时间和文字。 删除关系：根据关系表（回复表）PK删除。 5，站内短信型 特点：主副表是同一个，关系表一般有时间字段，有主键，重点在关系表文字型的字段用来说明每次发生关系的内容（消息）或者其他标记位来表示文字已读状态时间等。 界面特点：回复文本框。 例如：站内短信（用户表-短信表-用户表），用户可能给用户群发或者单发，有标记位来表示文字已读状态时间等。 增加关系：不管有没有组合纪录，insert之，纪录时间和文字。 删除关系：根据关系表（回复表）PK删除。 6，用户好友型
ORACLE 多表关联UPDATE 语句 为了方便起见,建立了以下简单模型,和构造了部分测试数据: 在某个业务受理子系统BSS中， --客户资料表 create table customers ( customer_id number(8) not null, -- 客户标示 city_name varchar2(10) not null, -- 所在城市 customer_type char(2) not null, -- 客户类型 ... ) create unique index PK_customers on customers (customer_id) 由于某些原因，客户所在城市这个信息并不什么准确，但是在 客户服务部的CRM子系统中，通过主动服务获取了部分客户20%的所在 城市等准确信息，于是你将该部分信息提取至一张临时表中： create table tmp_cust_city ( customer_id number(8) not null, citye_name varchar2(10) not null， customer_type char(2) not null ) 1) 最简单的形式 --经确认customers表中所有customer_id小于1000均为'北京' --1000以内的均是公司走向全国之前的本城市的老客户:) update customers set city_name='北京' where customer_id<1000 2) 两表(多表)关联update -- 仅在where字句中的连接 --这次提取的数据都是VIP，且包括新增的,所以顺便更新客户类别update customers a -- 使用别名 set customer_type='01' --01 为vip，00为普通 where exists (select 1 from tmp_cust_city b where b.customer_id=a.customer_id ) 3) 两表(多表)关联update -- 被修改值由另一个表运算而来 update customers a -- 使用别名 set city_name=(select b.city_name from tmp_cust_city b where b.customer_id=a.customer_id) where exists (select 1
目录 一Codd的RDBMS1２法则——RDBMＳ的起源 二关系型数据库设计阶段 三设计原则 四命名规则 数据库设计，一个软件项目成功的基石。很多从业人员都认为,数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分,所以也会把数据库设计想的如此简单。其实不然,数据库设计也是门学问。 从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计(后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ＯRM的开发者,设计的数据库往往更为合理,更能适应需求的变化,如果追其原因，笔者个人猜测是因为数据库的规范化,与OO的部分思想雷同（如内聚）。而ＤＢA,设计的数据库的优势是能将ＤBMS的能力发挥到极致,能够使用ＳＱL和DBMS实现很多程序实现的逻辑，与开发者相比，ＤＢA优化过的数据库更为高效和稳定。如标题所示,本文旨在分享一名开发者的数据库设计经验,并不涉及复杂的SQＬ语句或DBMS使用,因此也不会局限到某种DBＭS产品上。真切地希望这篇文章对开发者能有所帮助,也希望读者能帮助笔者查漏补缺。 一 Codd的RＤBMS12法则——ＲＤBMS的起源 Eｄgａr Frank Cｏdd（埃德加·弗兰克·科德)被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Ｃodd 博士发布了１2条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。 1. 信息法则关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2. 保证访问法则依靠表名、主键值和列名的组合,保证能访问每个数据项。 3. 空值的系统化处理支持空值(ＮULL）,以系统化的方式处理空值，空值不依赖于数据类型。 4. 基于关系模型的动态联机目录数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同 样的表示方式,即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用 户可以访问的表中。 5. 统一的数据子语言法则一个关系数据库系统可以支持几种语言和多种终端使用方式,但必须至少 有一种语言，它的语句能够一某种定义良好的语法表示为字符串,并能全面地支持以下所有规 则：数据定义、视图定义、数据操作、约束、授权以及事务。(这种语言就是ＳＱL) 6. 视图更新法则所有理论上可以更新的视图也可以由系统更新。 7. 高级的插入、更新和删除操作把一个基础关系或派生关系作为单个操作对象处理的能力不仅适 应于数据的检索,还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视 作集合。 8. 数据的物理独立性不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动 都保持着逻辑上的不变性。 9. 数据的逻辑独立性当对表做了理论上不会损害信息的改变时,应用程序和终端活动都会保持逻辑 上的不变性。 10. 数据完整性的独立性专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
一对一模型 身份证----------用户 建立模型之前首先得想一下要建立一对一的模型的思路，建立模型思路才是最重要的，思路想好了用工具很快就会生成。 一对一模型的建立有两种方式： 相同主键 (继承来实现，只继承主键) 唯一外键：一对多的一种特殊形式（外键是unique）1、相同主键型的一对一模式 （1）先创建两个概念模型 身份证 用户
用户的概念模型中没有设置主键 （2）用inheritance，从用户模型连接到身份证模型 （3）双击设置继承关系，选择inherit only primary altributes，只继承主键属性，否则会把所有属性在用户里再显示
（4）tool--转换成物理模型
（5）Database--生成脚本文件，去掉check model（如果没有连接pl/sql就选script generation） （6）如果面板上还有其他模板，勾选掉
（7）接下来确定，就可以成功生成脚本文件了。。。 用生成的脚本文件在plsql的命令窗口运行，生成两个表，插入数据 先插入身份证 再插入用户表信息
想要在用户表中加入身份证号是3的用户就会出错。idnum既是用户表的主键又是用户表的外键。 2、唯一外键型的一对一模型 （1）各自创建两个概念模型都有主键 （2）表A-------表B建立一对多关系 （3）转换为物理模型 （4）生成脚本文件 （5）在脚本文件里把有外键的一个表的外键加上unique约束 （6）在pl/sql中运行脚本文件生成的两个表就是一对一关系。 多对多模型 学生--------课程 要实现多对多的先想一下思路