包含的表主要有
列车（列车编号，车种，始发站，始发站，终到站，发时，到时，里程）
车站内（车站id，车站名）
经过（列车编号，车站名，站次，里程，到时，发时）
车票（车票编号，车次，发站，容到站，发站次，到站次，发时，到时，座位类型，座位号，车票日期，票价）
主要是这四个表，查询插入操作有些复杂不过都能完成
详细看列车票务系统数据库课程设计说明书，文库里有
② 那个我也想要一个数据库设计事例，就是火车售票管理SQL
目录
概述： 5
1. 需求分析 5
1.1 用户需求： 5
1.2 业务流程分析： 6
1.3 信息需求分析 6
1.4 功能需求分析： 7
2. （数据库）概念（模型）设计 8
2.1构思ERD的四条原则及根据这些原则相应得出的实体、联系及其属性： 9
2.2、系统具体E-R图： 9
3. （数据库）逻辑（模型）设计 10
3.1 一般逻辑模型设计： 10
3.2 具体逻辑模型设计： 11
4. 数据库物理设计与数据库保护设计 12
5. 处理功能设计 12
5.1 主控模块设计： 12
5.2 子模块设计： 13
6. 数据库应用系统的实现 14
6.1 数据库及其表结构的建立： 14
6.2 创建表的相关视图： 16
6.3 各表关系图， 16
6.4 数据输入：利用系统录入数据，如下图为各表内容： 17
6.5 模块实现： 18
7. 数据库应用系统运行 26
7.1 写出系统操作使用的简要说明。 26
7.2 按使用说明运行系统并打印出运行结果。 26
7.3 系统评价： 27
报告内容
概述：
随着国民经济快速发展, 人们出行、交通越来越频繁, 对服务的快捷、便利性要求也越来越高。从而对客运行业的建设与管理提出了更高的要求。为适应和推动客运行业的发展, 各种交通公司和部门开始广泛采用使用日趋成熟的计算机技术和数据库技术来实现票务信息的现代化管理，具有手工管理所无法比拟的优点，如：检索迅速，查找方便，可靠性高，存储量大，保密性好，寿命长，成本底等。这些优点能够极大地提高信息管理和业务管理的效率。
本学生火车订票系统正是通过数据库存储信息实现高效率管理。该实验设计首先进行需求分析，然后在需求文档的指导下实现系统的功能，如操作员的信息管理功能及普通学生的火车信息查询、订票、退票等功能，最终实现的是学生购得一张自己满意的票券，同时力求通过数据库系统及计算机在其中的运用达到提高工作效率,节约人力资源的效果。
1. 需求分析
1.1 用户需求：
(一）、问题描述：
学生火车票定票系统
(1)背景：一年两次的火车票订票管理
(2)主要实现以下功能：
1)学生基本信息的管理，尤其是所在地
2)学生购票的基本信息，尤其是价钱和车票目的地
3)购票以后的分发管理
4)退票的管理
5)信息的统计和查询
6)操作员管理
(二）、目的及现状：
1）、实验目的：
数据库设计就是要使学生采用本课程中学习的数据库设计方法，运用其基本思路与主要图表工具完成一个自己所了解的业务的数据库应用系统信息需求分析与数据库的概念设计、逻辑设计、物理设计以及处理功能设计，用自己熟悉的数据库管理系统、程序设计语言及其相关开发工具实现该系统，并运行、评价、改进之；在此基础上严格按本大纲所附报告提纲撰写课程设计报告。通过本设计进一步弄懂数据库系统及其相关的基本概念，理解数据库系统的系统结构、主要特点，掌握数据库设计的原理、方法及其基本过程，初步具备数据库应用设计的能力，初步形成运用数据库应用系统解决管理决策中的实际问题的基本素质。
2）、现状和系统要求：
在传统模式下利用人工进行火车订票业务，存在着较多的缺点，如：效率底，保密性差，时间一长将产生大量的文件和数据，更不便于查找，更新，维护等。诸如这些情况，给各相关部门工作人员带来了很大困难，严重影响了他们的工作效率。运用计算机技术和数据库技术来实现票务信息的现代化管理，具有手工管理所无法比拟的优点，如：检索迅速，查找方便，可靠性高，存储量大，保密性好，寿命长，成本底等。这些优点能够极大地提高信息管理和业务管理的效率。
在本系统中，系统用户共有两种, 并根据用户权限的不同而实现不同的功能，如操作员
拥有添加、修改、删除某火车相关信息及修改自己的个人信息的功能。学生有对车票信息、、哪一车次哪天还剩余多少张票和自己所订票券的查询功能，订票功能及退票功能。系统利用计算机和数据库的高效率大大减轻了学校票点工作人员的劳动强度, 提高了各部门的工作效率。
1.2 业务流程分析：
（一）、描述系统的业务流程：
本系统共有两种用户, 根据用户权限的不同而实现不同的功能。
操作员的权限最大，他进入系统必须先登录。操作员可以添加、修改、删除某车票的相关信息，可以修改自己的个人信息；查询、删除学生的订票情况，确认学生是否已付款取票等。
学生可以按目的地的车次对车票信息进行查询，可以订票，订票时须录入自己的信息及所选择的车次，系统将检查该车次票数是否已订完或不足，若已订完或不足则提示错误信息并返回到订票界面，订票成功后将生成订票单。学生还可以对自己所订的票券即订票单进行查询，以及查询哪一车次哪天还剩余多少张票。用户付款和取票可在学校票点完成。
（二）、初步业务流程图：
1.3 信息需求分析
1.3.1 资料收集
1.3.2 事项分析：
在本火车票订票系统中，各资料的基本数据项列举如下：
学生资料：学号，姓名，密码，所在学院，专业，班级，电话，目的城市
车票基本信息：车次号，出发站，开车时间，到达站，到达时间，车票种类，余票数
车次详细信息：ID号，车次号，途径站，票价，
订票单信息：订单号，订票人学号，订单时间，付款取票与否
订票具体信息：ID号，订单号，所得车次号，目的城市，订票数，总票价，取票时间
订票点信息：票点号，票点主任的员工号，联系电话，所在校区
操作员资料：员工号，票点号，密码，姓名，性别，电话
1.4 功能需求分析：
（一）、完善业务流程图：
（二）、功能层次图：
本系统共有两种用户, 根据用户权限的不同而实现不同的功能，如操作员查询、添加、修改、删除某火车相关信息及查询、修改自己的个人信息的功能。学生对车票信息、、哪一车次哪天还剩余多少张票和订票功能以及对自己所订票券的查询功能、退票功能。
2. （数据库）概念（模型）设计
2.1构思ERD的四条原则及根据这些原则相应得出的实体、联系及其属性：
① 原则1 （确定实体）：能独立存在的事物，例如人、物、事、地、团体、机构、活动、事项等等，在其有多个由基本项描述的特性需要关注时，就应把它作为实体。
在本系统中，实体主要有学生、操作员、车票信息、车票详细信息表、订票单，订票详细信息表，订票点。
②原则2 （确定联系）：两个或多个实体间的关联与结合，如主管，从属，组成，占有，作用，配合，协同等等，当需要予以关注时，应作为联系。实体间的联系可分为一对一、一对多、多对多等三类，在确定联系时还要确定其类型。
在本系统中，学生、车票信息、订票单和订票详细信息表之间存在“订购”的联系，一个车票信息可以被多个学生购买，而一个学生只可以购买多个车次所属的一到两张车票，它们之间的联系是一对多的“购买”联系，同时一次登录无论订多少车次只生成一张订票单。订票点和操作员之间存在“隶属”的联系，它们之间的联系是一对多的“隶属”联系；车票信息和车票详细信息表之间存在“包含”与被包含的关系；订票单和订票详细信息表之间也存在“包含”与被包含的关系。
③原则3 （确定属性）：实体的属性是实体的本质特征。实体应有标识属性（能把不同个体区分开来的属性组），并指定其中一个作为主标识。联系的属性是联系的结果或状态。
从这条原则可得到实体和联系的属性如下：
学生（学号，姓名，密码，所在学院，专业，班级，电话，目的城市）
车票基本信息（车次号，出发站，开车时间，到达站，到达时间，车票种类，余票数）
车次详细信息（ID号，车次号，途径站，票价）
订票单信息（订单号，订票人学号，订单时间，付款取票与否）
订票具体信息（ID号，订单号，所得车次号，目的城市，订票数，总票价，取票时间）
订票点（票点号，票点主任的员工号，所在校区，电话）
操作员（员工号，票点号，密码，姓名，性别，电话）
④原则4（一事一地）：信息分析中得到的基本项要在且仅在实体联系图中的一个地方作为属性出现。
根据以上的分析，可以画出本系统的原始ERD的基本结构。如
2.2、系统具体E-R图：
3. （数据库）逻辑（模型）设计
3.1 一般逻辑模型设计：
（一）、由ERD导出一般关系模型的四条原则：
原则1（实体转换为关系模式）：ERD中每个独立的实体转换为一个关系模式，实体的属性组成关系的属性，实体的主标识转换成关系的主码。
原则2（从实体及其主从联系转换为关系模式）：ERD中一个从实体及其主从联系转换为一个关系，从实体的属性及其主实体关系的属性组成的属性，其主实体关系的主码，在主从关系联系为一对多联系时还要加上可把同一主实体个体所对应的从实体个体区分开来的，从实体的一组属性，作为该关系的主码。对子类实体可作类似一对一联系的从实体的转换。
原则3（一对多联系在关系模式中的表示）：ERD中的一个一对多联系通过在其“多”实体关系上增加“1”实体关系的主码（作为外码）和联系本身的属性来表示。
原则4（多对多联系转换为关系）：ERD中的一个多对多联系转换为一个关系，其被联系实体关系的主码和该联系本身的属性一起组成的属性，被联系关系的主码组成该关系的复合主码。
（二）、数据库初步构思的关系框架：
通过ERD转换为一般关系模型四条原则分析，得到须在数据库中进行存储的一般关系模型如下（带下划线的为主码，带#的为外键）：
学生（学号，姓名，密码，所在学院，专业，班级，电话，目的城市）
车票基本信息（车次号，出发站，开车时间，到达站，到达时间，车票种类，余票数）
车次详细信息（ID号，车次号#，途径站，票价）
订票单信息（订单号，订票人学号#，订单时间，付款取票与否）
订票具体信息（ID号，订单号#，所得车次号#，目的城市，订票数，总票价，取票时间）
订票点（票点号，票点主任的员工号#，所在校区）
操作员（员工号，密码，姓名，性别，电话）
3.2 具体逻辑模型设计：
（1）、Student表：用来保存学生信息：
项名 类型 长度 小数位 值域 主键 外键 空键
学号 字符 12 是 非空
姓名 字符 20 非空
密码 字符 12 非空
学院 字符 40 非空
专业 字符 30 非空
班级 数据 4 0 >0 非空
电话 字符 12 非空
目的城市 字符 30 非空
（2）、Ticket表：用来保存车票信息表
项名 类型 长度 小数位 值域 主键 外键 空键
车次号 字符 20 是 非空
出发站 字符 30 非空
开车时间 日期 8 非空
到达站 字符 30 非空
到达时间 日期 8 非空
车票种类 字符 20 非空
余票数 数据 8 0 >0 非空
（3）、Citysite表：用来保存车票详细信息表：
项名 类型 长度 小数位 值域 主键 外键 空键
ID号 整数，自动编号 8 是 非空
车次号 字符 20 是 非空
途径城市 字符 30 非空
票价 decimal 非空
（4）、Ticketsite表：用来保存订票点表：
项名 类型 长度 小数位 值域 主键 外键 空键
票点号 整数，自动编号 8 0 是 非空
票点主任员工号 整数，自动编号 8 0 是 非空
联系电话 字符 12 非空
所在校区 字符 40 非空
（5）、Admin表：用来保存操作员表：
项名 类型 长度 小数位 值域 主键 外键 空键
员工号 整数，自动编号 8 0 是 非空
用户名 字符 20 非空
密码 字符 12 非空
姓名 字符 20 非空
性别 字符 4 非空
电话 字符 12 非空
（6）、Book表：用来保存订单表：
项名 类型 长度 小数位 值域 主键 外键 空键
订单号 整数，自动编号 8 0 是 非空
学号 字符 是 非空
订单时间 字符 非空
付款取票与否 整数 2 0 非空
（7）、Ticket表：用来保存取票单表：
项名 类型 长度 小数位 值域 主键 外键 空键
ID号 整数，自动编号 8 0 是 非空
取票号 字符 8 0 是 非空
车次号 字符 是 非空
目的城市 字符 非空
订票数 数据 8 0 >0 非空
总票价 Decimal 非空
取票时间 日期 8 非空
4. 数据库物理设计与数据库保护设计
根据表的结构关系，本系统采用SQL Server 2000数据库。SQL Server 2000是微软公司关系型数据库产品，它是在由MS SQL Server 7.0建立的坚固基础之上产生的。客户的需求极大的推动了该产的革新，SQL Server2000在易用性、可缩放性和可靠性，以及数据仓库等诸多方面有了很大的增强。这使得SQL Server 2000在很多数据库产品发展最快的应用领域（如电子商务、移动计算、分支自动化、商业级应用和数据交换中心等）中成为领先者
在数据库中创建表的同时须创建相关的索引。索引就是加快检索表中数据的方法。数据库的索引类似于书籍的索引。在书籍中，索引允许用户不必翻阅完整个书就能迅速地找到所需要的信息。在数据库中，索引也允许数据库程序迅速地找到表中的数据，而不必扫描整个数据库。本数据库表较为简单，且每个表中定义主键约束或者唯一性键约束，已经间接创建了索引，故无需再创建索引。
5. 处理功能设计
5.1 主控模块设计：
(1)、登录系统模块：
在登录窗体界面中，你可以输入代码和密码，选择你的身份（操作员或系统管理员），确认后就可进入主界面窗体。如果你是学生，且还没注册，可以在此窗体界面上点击“注册”，在注册界面输入所要求的项，确定后重新返回登录界面，用你刚注册的账号登录进入主界面。
在主界面中包含上述模块图的几部分，根据身份，即是用户或者管理员，对应权限不同，分为不同的主界面，即用户主界面和管理员主界面。
（2）、系统设置模块图：
用户：在此模块用户可以查询、修改自身注册信息以及退出登录，退出系统后将返回登录界面。
管理员模块：在此模块管理员除了拥有用户的各项设置外还可以注册新的管理员，但为了安全起见，此功能只有当登录人是票点主任时才可执行。
5.2 子模块设计：
5.2.1、管理员模块
1、车票信息管理模块:在此模块，管理员可以执行车票信息录入、查询、删除和修改功能，不过删除和修改功能须当该车次没有被预订的情况下才可执行。
2、订票管理模块：在此模块，管理员可以查询所有订单情况、已付款取票和未付款取票的订单情况，还可以按学号查询某学生的订票情况以及各种统计信息，并在学生来付款取票时执行“付款”操作。另外还可以在订单已付款或学生取消订单时删除订单。
5.2.2、用户模块：
1、订票管理模块：在此模块，用户可以查询车票信息和自身订票情况。查询车票情况分为按车次、按目的地、按起始站—目的站查询，当查询到自身所想要的车票时即可订票，但注意预定票的目的地须与学生家乡所在城市相符，否则系统不允许订票；查询自身订票情况包括订单信息及金额统计，还须注意订票信息上要求的取票期限，订票人须在规定期限内去所在校区的票点付款取票，逾期票点工作人员将不予处理。
2、用户小贴士模块：在这里，用户将了解本订票系统的订票流程及相关规定及用户订票后付款取票地点的信息等。
6. 数据库应用系统的实现
6.1 数据库及其表结构的建立：
利用SQLServer企业管理器创建数据库Tickets，然后创建表：
1、学生表Book
create table Student
(Sno varchar(12) primary key, Sname varchar(20) not null,
Ssex varchar(4) not null, Spw varchar(12) not null, //密码
Sadm varchar(40) not null, //学院
Sdept varchar(30) not null, Sclass numeric(4) not null,
Stel varchar(12) not null, //电话
Semail varchar(50) not null, Shcity varchar(30) not null //所在地
)；
2、车票信息表Ticket
create table Ticket
(Tno varchar(20) primary key, //车次号
Startcity varchar(30) not null, Starttime varchar(20) not null,
Endcity varchar(100) not null, Endtime varchar(20) not null,
Ttype varchar(20) CHECK (Ttype IN('硬座','软座','硬卧','软卧')),
Tickets int not null //票数
);
3、车次站次信息表Citysite
create table Citysite
(Cityno numeric(8) identity(1,1), //票点号
Tno varchar(20), City varchar(100),
Tprice decimal not null, //票价
primary key (Cityno,Tno),
foreign key (Tno) references Ticket(Tno) on delete cascade
)
4、订票单表Book
create table Book
(Bno numeric(8) identity(1,1) primary key, Sno varchar(12),
Maketime datetime not null, judge int,
foreign key (Sno) references Student(Sno),);
5、订票详细信息表Bookno
create table Bookno
(ID numeric(8) identity(1,1) primary key,
Bno numeric(8), Tno varchar(20), City varchar(100),
Booktime varchar(20) not null, Ticketnums int not null,
Price decimal not null, //票价
Pickdate datetime not null, foreign key (Tno) references Ticket(Tno),
foreign key (Bno) references Book(Bno));
6、操作员表Operater
create table Operater
(Adname varchar(20) primary key, //登录用户名
Adpw varchar(12) not null, //登录密码
Opname varchar(20) not null, //员工真实姓名
Opsex varchar(4) not null, Optel varchar(12) not null,
Opemail varchar(50) not null);
7、订票点表Ticketsite
create table Ticketsite
(Siteno numeric(8) primary key identity, //票点号
Adname varchar(20), // 票点主任登录名
Sitetel varchar(12) not null, Siteaddr varchar(40),
foreign key (Adname) references Operater(Adname));
//为安全起见，学校各校区订票点内容的添加要以直接输入数据库的方式进行
insert into Ticketsite(Adname,Sitetel,Siteaddr) values('linyp','870432','龙洞校区行政楼205')
insert into Ticketsite(Adname,Sitetel,Siteaddr) values('admin','87084432','大学城校区E区205')
6.2 创建表的相关视图：
1、创建V_Book视图,得到对于某种车票的订票人数和订票张数
create view V_Book(Tno,stu_no,sumticket)
as
select Tno,count(distinct Sno),sum(Ticketnums) from Bookno,Book
where Bookno.Bno=Book.Bno group by Tno
2、创建W_Book视图,得到对于所有订票学生的人数和订票总张数
create view W_Book(stu_nums,sumtickets)
as select count(distinct Sno),sum(Ticketnums) from Bookno,Book
where Bookno.Bno=Book.Bno
3、创建P_Book视图,得到对于已付款取票的人数和车票总张数
create view P_Book(cout_no,cout_nums)
as select count(distinct Sno),sum(Ticketnums) from Bookno,Book
where Bookno.Bno=Book.Bno and judge=1
4、创建M_Book视图, 得到对于某一订票的总金额
create view M_Book(Allprice)
as select sum(Tprice*Ticketnums) from Book,Bookno,Citysite
where Bookno.Bno=Book.Bno and Bookno.Tno=Citysite.Tno and Bookno.City=Citysite.City
6.3 各表关系图，
易知表Ticket与表Citysite之间是父表与子表的关系:
表Book与表Bookno之间也是父表与子表的关系:
它们之间都是父表对子表的一对多的关系。
根据表之间的结构关系图，可以得出各表的完整性约束条件如下图：
表名 主键列名 外键
外键列名 参照表
Student Sno 无
Ticket Tno 无
Citysite Cityno Tno Ticket
Book Bno Sno Student
Bookno ID Bno,Tno Book,Ticket
Operater Adname 无
Ticketsite Siteno Adname Operater
6.4 数据输入：利用系统录入数据，如下图为各表内容：
6.5 模块实现：
本次系统设计我前台采用jsP技术,后台采用SQL Server 2000,操作系统采用Windows XP。
JSP(JavaServer Pages)是由Sun Microsystems公司倡导、许多公司参与一起建立的一种动态网页技术标准，它是在传统的网页HTML文件(*.htm,*.html)中插入Java程序段(Scriptlet)和JSP标记(tag)，从而形成JSP文件(*.jsp)。JSP具备了Java技术的简单易用，完全的面向对象，具有平台无关性且安全可靠，主要面向因特网的所有特点。
③ Power Designer设计影院售票系统
地址: http://web.52im.net/article.php?articleid=6747
Power Designer是Sybase公司的CASE工具集，使用它可以方便地对管理信息系统进行分析设计，它几乎包括了数据库模型设计的全过程。利用Power Designer可以制作数据流程图、概念数据模型、物理数据模型，可以生成多种客户端开发工具的应用程序，还可为数据仓库制作结构模型，也能对团队设计模型进行控制。Power Designer的4种模型:概念数据模型 (CDM)物理数据模型 (PDM) 面向对象模型 (OOM) 业务程序模型 (BPM) 我主要介绍一下PDM:PDM 叙述数据库的物理实现,帮助你考虑真实的物理实现的细节。你能通过修正PDM来适合你的表现或物理约束。主要目的是把CDM中建立的现实世界模型生成特定的DBMS脚本，产生数据库中保存信息的储存结构，保证数据在数据库中的完整性和一致性。PDM是适合于系统设计阶段的工具。简单说:就是PDM可以自动生成诸如'create table'之类的sql脚本.在数据建模过程中，我们建立概念数据模型，通过正向工程生成物理数据模型，生成数据库建库脚本，最后将物理数据模型生成关系数据库。系统数据库设计人员希望能够将数据库设计和关系数据库生成无缝地集成起来，如何保证物理数据模型与其对应数据库之间的双向同步成为数据建模非常关键的一点。Powerdesigner作为强大的Case工具，为我们提供了方便的逆向工程特性。可以将目前所有流行的后端数据库(包括Sybase、DB2、Oracle等)的结构信息通过逆向工程加入到PowerDesigner的物理数据模型和概念数据模型中，包括表、索引、触发器、视图等。下面说一下如何用PowerDesigner进行逆向工程.1.我用的数据库是oracle9i,我为了访问oracle数据库,在我的机器上安装了oracle客户端(提供了oracle客户端的驱动程序,而精简客户端则不可以),配置一个名称为mylcl的服务:MYLCL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.3.106)(PORT = 1521)) ) (CONNECT_DATA = (SID = pwsc) ) )用户名为:testuser,密码为test. 2.在pd中,新建一个pdm,选择数据库为oracle9i3.选择Database->configure connections,转到system dsn标签，点击"添加",选择驱动程序,由于我的数据库是oracle,所以我选择"oracle in oraclient10g_home1"(安装了oracle客户端才有这个驱动,而精简客户端没有此驱动)4.在data source name 中,可以随便命名一个"ora-test",在tns-server name中选择第一步中的服务名称:mylcl.点击"test connection",输入用户名密码,connection ok!5.点击database->reverse engineer database ,选择odbc datasource:ora-test.然后点击确定哈哈,看见什么了.我就不说了吧pdm的图表如何?其实pd还可以通过sql来进行反向工程,我就不说了特此存档.同时也希望对大家有帮助.
④ 不就是一个订票网站吗，12306的核心模型设计思路究竟复杂在哪儿
12306这个系统，核心要解决的问题是网上售票。涉及到个角色使用该系统：用户、铁道部。用户的核心诉求是查询余票、购票；铁道部的核心诉求是 售票。购票和售票其实是一个场景，对用户来说是购票，对铁道部来说是售票。因此，我们要设计一个在线的网站系统，解决用户的查询余票、购票，以及铁道部的 售票这3个核心诉求。看起来，这3个场景都是围绕火车票展开的。
查询余票：用户输入出发地、目的地、出发日三个条件，查询可能存在的车次，用户可以看到每个车次经过的站点名称，以及每种座位的余票数量。
购票：购票分为订票和付款两个阶段，本文重点分析订票的模型设计和实现思路。
其实还有很多其他的需求，比如给不同的车次设定销售座位数配额，以及不同的区段设置不同的限额。但相比前面两个需求来说，我觉得这个需求相对次要一些。
需求分析
确实，12306也是一个电商系统，而且看起来商品就是票了。因为如果把一张票看成是一个商品，那购票就类似于购买商品，然后每张票都有库存，商品 也有库存的概念。但是如果我们仔细想想，会发现12306要复杂很多，因为我们无法预先确定好所有的票，如果非要确定，那只能通过穷举法了。
我们以北京西到深圳北的G71车次高铁为例（这里只考虑南下的方向，不考虑深圳北到北京西的，那是另外一个车次，叫G72），它有17个站（北京西 是01号站，深圳北是17号站），3种座位（商务、一等、二等）。表面看起来，这不就是3个商品吗？G71商务座、G71一等座、G71二等座。大部分轻 易喷12306的技术人员（包括某些中等规模公司的专家、CTO）就是在这里栽第一个跟头的。实际上，G71有136*3=408种商品（408个 SKU），怎么算来的？如下：
如果卖北京西始发的，有16种卖法（因为后面有16个站），北京西到：保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商 品，同理，石家庄上车的，有15种下车的可能，以此类推，单以上下车的站来计算，有136种票：16+15+14….+2+1=136。每种票都有3种座 位，一共是408个商品。
为了方便后面的讨论，我们先明确一下票是什么？
一张票的核心信息包括：出发时间、出发地、目的地、车次、座位号。持有票的人就拥有了一个凭证，该凭证表示持有它的人可以坐某个车次的某个座位号， 从某地到某地。所以，一张票，对用户来说是一个凭证，对铁道部来说是一个承诺；那对系统来说是什么呢？不知道。这就是我们要分析业务，领域建模的原因，我 们再继续思考吧。
明白了票的核心信息后，我们再看看G71这个车次的高铁，可以卖多少张票？
讨论前先说明一下，一辆火车的物理座位数（站票也可以看成是一种座位，因为站票也有数量配额）不等于可用的最大配合。所有的物理座位不可能都通过 12306网站来销售，而是只会销售一部分，比如40%。其余的还是会通过线下的方式销售。不仅如此，可能有些站点上车的人会比较多，有些比较少，所以我 们还会给不同的区间配置不同的限额。比如D31 北京南至上海共有765张，北京南有260张，杨柳青有80张，泰安有76张。如果杨柳青的80张票售完就会显示无票，就算其他站有票也会显示无票的。每 个车次肯定会有各种座位的配额和限额的配置的，这种配置我目前无法预料，但我已经把这些规则都封装近车次聚合根里了，所有的配置策略都是基于座位类型、站 点、区间配置的。关于票的配置抽象出来，我觉得主要有3种：1）某个区段最多允许出多少张；2）某个区段最少允许出多少张；3）某个站点上车的最多多少 张；当用户订票时，把用户指定的区段和这3种配置条件进行比较，3个条件都满足，则可以出票。不满足，则认为无票了。下面举个例子：
ABCDEFG，这是所有站点。座位总配额是100，假设B站点上车，E站下车的人比较少，那我们就可以设定BE这个区段最多只能出10张票。所 以，只要是用户的订票是在这个区段内的，就最多出10张。再比如，一列车次，总共100个座位配额，希望全程票最少满足80张，那我们只要给AG这个区段 设定最少80张。那任何订票请求，如果是子区间的，就不能超过100-80，即20张。这两种条件必须同时满足，才允许出票。
但是，不管如何做配额和限额，我们总是针对某个车次进行配置，这些配置只是车次内部售票时的一些额外的判断条件（业务规则），不影响车次模型的核心 地位和对外暴露的功能。所以，为了本文讨论的清楚起见，我后续的讨论都不涉及配额和限额的问题，而是认为任何区段都可以享受火车最大的物理座位数。
并且，为了讨论问题方便，我们减少一些站点来讨论。假设某个车次有A,B,C,D四个站点。那001这个人购买了A,B这个区间，系统会分配给 001一个座位x；但是因为001坐到B站点后会下车，所以相当于x这个座位又空出来了，也就是说，从B站点开始，系统又可以认为x这个座位是可用的。所 以，我们得出结论：同一个座位，其实可以同时出售AB,BC这两张票。通过这个简单的分析，我们知道，一列火车虽然只有有限的座位数，比如1000个座 位。但可以卖出的票远远不止1000个。还是以A,B,C,D四个站点为例，假如火车总共有1000个座位，那AB可以卖1000张，BC也可以卖 1000张，同样，CD也可以卖1000张。也就是说，理论上最多可以卖出3000张票。但是如果换一种卖法，所有人都是买ABCD的票，也就是说所有的 票都是经过所有站点的，那就是最多只能卖出1000张票了。而实际的场景，一定是介于1000到3000之间。然后实际的G71这个车次，有17个站，那 到底可以卖出多少个票，大家应该可以算了吧。理论上这17个站中的任意两个站点之间所形成的线段，都可以出售为一张票。我数学不好，算不太清楚，麻烦有数 学好的人帮我算算，呵呵。
通过上面的分析，我们知道一张票的本质是某个车次的某一段区间（一条线段），这个区间包含了若干个站点。然后我们还发现，只要区间不重叠，那座位就不会发生竞争，可以被回收利用，也就是说，可以同时预先出售。
另外，经过更深入的分析，我们还发现区间有4种关系：1）不重叠；2）部分重叠；3）完全重叠；4）覆盖；不重叠的情况我们已经讨论过了，而覆盖也 是重叠的一种。所以我们发现如果重叠，比如有两个区间发生重叠，那重叠部分的区间（可能夸一个或多个站点）是在争抢座位的。因为假设一列火车有100个座 位，那每个原子区间（两个相邻站点的连线），最多允许重叠99次。
所以，经过上面的分析，我们知道了一个车次能够出售一张车票的核心业务规则是什么？就是：这张车票所包含的每个原子区间的重叠次数加1都不能超过车次的总座位数，实际上重叠次数+1也可以理解为线段的厚度。
模型设计
上面我分析了一下票的本质是什么。那接下来我们再来看看怎么设计模型，来快速实现购票的需求，重点是怎么设计商品聚合以及减库存的逻辑。
传统电商的思路
如果按照普通电商的思路，把票（站点区间）设计为商品（聚合根），然后为票设计库存数量。我个人觉得是很糟糕的。因为一方面这种聚合根非常多（上面 的G71就有408个）；另一方面，即便枚举出来了，一次购票也一定会影响非常多其他聚合根的库存数量（只要被部分或全部重叠的区间都受影响）。这样的一 次订单处理的复杂度是难以评估的。而且这么多聚合根的更新要在一个事务里，这不是为难数据库吗？而且，这种设计必然带来大量的事务的并发冲突，很可能导致 数据库死锁。总之，我认为这种是典型的由于领域模型的设计错误，导致并发冲突高、数据持久化落地困难。或者如果要解决并发问题，只能排队单线程处理，但是 仍然解决不了要在一个事务里修改大量聚合根的尴尬局面。听说12306是采用了Pivotal Gemfire这种高大上的内存数据库，我对这个不太了解。我不可想象要是不使用内存数据库，他们要怎么实现车次内的票之间的数据强一致性（就是保证所有 出售的票都是符合上面讨论的业务规则的）？所以，这种设计，我个人认为是思维定势了，把火车票看成是普通电商的商品来看待。所以，我们有时做设计又要依赖 于经验，又要不能被以往经验所束缚，真的不容易，关键还是要根据具体的业务场景多多深入分析，尽量分析抽象出问题的本质出来，这样才能对症下药。那是否有 其他的设计思路呢？
我的思路
聚合设计
通过上面的分析我们知道，其实任何一次购票都是针对某个车次的，我认为车次是负责处理订票的聚合根。我们看看一 个车次包含了哪些信息？一个车次包括了：1）车次名称，如G71；2）座位数，实际座位数会分类型，比如商务座20个，一等座200个；二等座500个； 我们这里为了简化问题，可以暂时忽略类型，我认为这个类型不影响核心的模型的设计决策。需要格外注意的是：这里的座位数不要理解为真实的物理座位数，很有 可能比真实的座位数要少。因为我们不可能把一个车次的所有座位都在网上通过12306来出售，而是只出售一部分，具体出售多少，要由工作人员人工指定。 3）经过的站点信息（包括站点的ID、站点名称等），注意：车次还会记录这些站点之间的顺序关系；4）出发时间；看过GRASP九大模式中的信息专家模式的同学应该知道，将职责分配给拥有执行该职责所需信息的类。我们这个场景，车次具有一次出票的所有信息，所以我们应该把出票的职责交给车次。另外学过DDD的同学应该知道，聚合设计有一个原则，就是：聚合内强一致性，聚合之间最终一致性。经 过上面的分析，我们知道要产生一张票，其实要影响很多和这个票对应的线段相交的其他票的可用数量。因为所有的站点信息都在车次聚合内部，所以车次聚合内部 自然可以维护所有的原子区间，以及每个原子区间的可用票数（相当于是库存数）。当一个原子区间的可用票数为0的时候，意味着火车针对这个区间的票已经卖完 了。所以，我们完全可以让车次这个聚合根来保证出票时对所有原子区间的可用票数的更新的强一致性。对于车次聚合根来说，这很简单，因为只是几次简单的内存 操作而已，耗时可以忽略。一列火车假如有ABCD四个站点，那原子区间就是3个。对于G71，则是16个。
怎么判断是否能出票
基于上面的聚合设计，出票时扣减库存的逻辑是：
根据订单信息，拿到出发地和目的地，然后获取这段区间里的所有的原子区间。然后尝试将每个原子区间的可用票数减1，如果所有的原子区间都够减，则购 票成功；否则购票失败，提示用户该票已经卖完了。是不是很简单呢？知道了出票的逻辑，那退票的逻辑也就很简单了，就是把这个票的所有原子区间的可用票数加 1就OK了。如果我们从线段的厚度的角度去考虑，那出票时，每个原子区间的厚度就是+1，退票时就是减一。就是相反的操作，但本质是一样的。
所以，通过这样的思路，我们将一次订票的处理控制在了一个聚合根里，用聚合根内的强一致性的特性保证了订票处理的强一致性，同时也保证了性能，免去 了并发冲突的可能性。传统电商那种把票单做类似商品的核心聚合根的设计，我当时第一眼看到就觉得不妥。因为这违背了DDD强调的强一致性应该由聚合根来保 证、聚合根之间的最终一致性通过Saga来保证的原则。
还有一个很重要的概念我想说一下我的看法，就是座位和区间的关系。因为有些朋友和我讲，考虑座位号的问题，虽然都能减1，座位号也必须是同一个。我 觉得座位是全局共享的，和区段无关（也许我的理解完全有误，请大家指正）。座位是一个物理概念，一个用户成功购买了一张票后，座位就会少一个，一张票唯一 对应一个座位，但是一个座位有可能会对应多张票；而区间是一个逻辑上的概念，区间的作用有两个：1）表示票的出发地和目的地；2）记录票的可用数额。如果 区间能连通（即该区间内的每个原子区间的可用数额都大于0），则表示允许拥有一个座位。所以，我觉得座位和票（区间）是两个维度的概念。
如何为票分配座位
我觉得车次聚合根内部应该维护所有该车次已经售出的票，已经出售的票的的本质是区间和座位的对应关系。系统处理订票时，用户提交过来的是一段区间。所以，系统应该做两个事情：
先根据区间去判断是否有可用的座位；
如果有可用座位，则再通过算法去选择一个可用的座位；
当得到一个可用座位后，就可以生成一张票了，然后保存这个票到车次聚合根内部即可。下面举个例子：
假设现在的情况是座位有3个，站点有4个
座位：1,2,3
站点：abcd
票的卖法1：
票1：ab,1
票2：bc,2
票3：cd,3
票4：ac,3
票5：bd,1
这种选座位的方式应该比较高效，因为总是优先从座位池里去拿座位，只有在万不得已的时候才会去回收可重复利用的票。
上面的4，5两个票，就是考虑回收利用的结果。
票的卖法2：
票1：ab,1
票2：bc,1
票3：cd,1
票4：ac,2
票5：bd,3
这种选座位的方式应该相对低效，因为总是优先会去扫描是否有可回收的座位，而扫描相对直接从座位池里去拿票总是成本相对要高的。
上面的2，3两个票，就是考虑回收利用的结果。
但是，优先从座位池里拿票的算法有缺陷，就是会出现虽然第一步判断认为有可用的座位，但是这个座位可能不是全程都是同一个座位。举例：
假设现在的情况是座位有3个，站点有4个
座位：1,2,3
站点：abcd
票的卖法3：
票1：ab,1
票2：bc,2
票3：cd,3
现在如果有人要买ad的票，那可用的座位有2，或者3。但是无论是2还是3，都要这个乘客中途换车位。比如卖给他座位2，那他ab是坐的座位2，但是bc的时候要坐座位1的。否则拿票2的那个人上车时，发现座位2已经有人了。而通过优先回收利用的算法，是没这个问题的。
所以，从上面的分析我们也知道选座位的算法该怎么写了，就是采用优先回收利用座位的算法。我认为不管我们这里怎么设计算法，都不影响大局，因为这一切都只发生在车次聚合根内部，这就是预先设计好聚合根，明确出票职责在哪个对象上的好处。
模型分析总结
我认为票不是核心聚合根，票只是一次出票的结果，一个凭证而已。
12306真正的核心聚合根应该是车次，车次具有出票的职责，一次出票具体做的事情有：
判断是否可出票；
选择可用的座位；
更新一次出票时所有原子区间的可用票数，用于判断下次是否能出票；
维护所有已售出的票，用于为选择可用座位提供依据；
通过这样的模型设计，我们可以确保一次出票处理只会在一个车次聚合根内进行。这样的好处是：
不需要依赖数据库事务就能实现数据修改的强一致性，因为所有修改只在一个聚合根内发生；
在保证数据强一致性的同时还能提供很高的并发处理能力，具体设计见下面的架构设计；
架构设计（非本文重点，没兴趣的朋友可以略过）
我觉得12306这样的业务场景，非常适合使用CQRS架构；因为首先它是一个查多写少、但是写的业务逻辑非常复杂的系统。所以，非常适合做架构层面的读写分离，即采用CQRS架构。而且应该使用数据存储也分离的CQRS。这样CQ两端才可以完全不需要顾及对方的问题，各自优化自己的问题即可。我们可以在C端使用DDD领域模型的思路，用良好设计的领域模型实现复杂的业务规则和业务逻辑。而Q端则使用分布式缓存方案，实现可伸缩的查询能力。
订票的实现思路
同时借助像ENode这样的框架，我们可以实现in-memory + Event Sourcing的架构。Event Sourcing技术，可以让领域模型的所有状态修改的持久化统一起来，本来要用ORM的方式保存聚合根最新状态的，现在只需要简单的通用的方式保存一个 事件即可（一次订票只涉及一个车次聚合根的修改，修改只产生一个事件，只需要持久化一个事件（一个JSON串）即可，保证了高性能，无须依赖事务，而且通 过ENode可以解决并发问题）。我们只要保存了聚合根每次变化的事件（事件的结构怎么设计，本文不做多的介绍了，大家可以思考下），就相当于保存了聚合 根的最新状态。而正是由于Event Sourcing技术的引入，让我们的模型可以一直存活在内存中，即可以使用in-memory技术。不要小看in-memory技术，in- memory技术在某些方面对提高命令的处理性能非常有帮助。比如就以我们车次聚合根处理出票的逻辑，假设某个车次有大量的命令发送到分布式消息队列，然 后有一台机器订阅了这个队列的消息，然后这台机器处理这个车次的订票命令时，由于这个车次聚合根一直在内存，所以就省去了每次要去数据库取出聚合根的步 骤，相当于少了一次数据库IO。这样的好处是，因为一个车次能够真正出售的票是有限的，因为座位就那么几个，比如就1000个座位，估计一般正常情况也就 出个2000个左右的票吧（具体能出多少张票要取决于区间的相交程度，上面分析过）。也就是说，这个聚合根只会产生2000个事件，也就是说只会有 2000个订票命令的处理是会产生事件，并持久化事件；而其余的大量命令，因为车次在内存计算后发现没有余票了，就不会做任何修改，也不会产生领域事件， 这样就可以直接处理下一个订票命令了。这样就可以大大提高处理订票命令的性能。
另外一个问题我觉得还需要提一下，因为用户订票成功后，还需要付款。但用户有可能不去付款或者没有在规定的时间内完成付款。那这种情况下，系统会自 动释放该用户之前订购的票。所以基于这样的需求，我们在业务上需要支持业务级别的2pc。即先预扣库存，也就是先占住这张票一定时间（比如15分钟），然 后付款成功后再真实给你这张票，系统做真正的库存修改。通过这样的预扣处理，可以保证不会出现超卖的情况。这个思路其实和传统电商比如淘宝这样的系统类 似，我就不多展开了，我之前写的Conference案例也是这样的思路，大家有兴趣的可以去看一下我之前录制的视频。
查询余票的实现思路
我觉得余票的查询的实现相对简单。虽然对于12306来说，查询的请求占了80%，提交订单的请求只占20%。但查询由于对数据没有修改，所以我们 完全可以使用分布式缓存来实现。我们只需要精心设计好缓存的key即可；缓存key的多少要看成本，如果所有可能的查询都设计对应的key，那时间复杂度 为1，查询性能自然高；但代价也大，因为key多了。如果想key少一点，那查询的复杂度自然要上去一点。所以缓存设计无非就是空间换时间的思路。然后， 缓存的更新无非就是：自动失效、定时更新、主动通知3种。通过CQRS架构，由于CQ两端是事件驱动的，当C端有任何状态变化，都会产生对应的事件去通知 Q端，所以我们几乎可以做到Q端的准实时更新。
同时由于CQ两端的完全解耦，Q端我们可以设计多种存储，如数据库和缓存（Redis等）；数据库用于线下维护关系型数据，缓存用户实时查询。数据 库和缓存的更新速度相互不受影响，因为是并行的。对同一个事件，可以10台机器负责更新缓存，100台机器负责更新数据库。即便数据库的更新很慢，也不会 影响缓存的更新进度。这就是CQRS架构的好处，CQ的架构完全不同，且我们随时可以重建一种新的Q端存储。不知道大家体会到了没有？
关于缓存key的设计，我觉得主要从查询余票时传递的信息来考虑。12306的关键查询是：出发地、目的地、出发日期三个信息。我觉得有两种key 的设计思路：1）直接设计了该查询条件的key，然后快速拿到车次信息，直接返回；这种方式就是要求我们系统已经枚举了所有车次的所有可能出现的票（区 间）的缓存key，相信你一定知道这样的key是非常多的。2）不是枚举所有区间，而是把每个车次的每个原子区间（相邻的两个站点所连成的直线）的可用票 数作为key。这样，key就非常少了，因为车次假如有10000个，然后每个车次平均15个区间，那也就15W个key而已。当我们要查询时，只需要把 用户输入的出发地和目的地之间的所有原子区间的可用票数都查出来，然后比较出最小可用票数的那个原子区间。则这个原子区间的可用票数就是用户输入的区间的 可用票数了。当然，到这里我提到考虑出发日期。我认为出发日期是用来决定具体是哪个车次聚合根的。同一个车次，不同的日期，对应的聚合根实例是不同的，即 便是同一天，也可能有多个车次聚合根，因为有些车次一天有几班的，比如上午9点发车的一班，下午3点发车的一般。所以，我们也只要把日期也作为缓存key 的一部分即可。