CN108804460A - 一种基于sql的查询语言 - Google Patents
一种基于sql的查询语言 Download PDFInfo
- Publication number
- CN108804460A CN108804460A CN201710302570.XA CN201710302570A CN108804460A CN 108804460 A CN108804460 A CN 108804460A CN 201710302570 A CN201710302570 A CN 201710302570A CN 108804460 A CN108804460 A CN 108804460A
- Authority
- CN
- China
- Prior art keywords
- logical
- sql
- dimension
- money
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供了一种基于SQL的查询语言,在抽取业务***中的各项维度和维度层次时,确定各项维度的层次之间的计算关系;维度的层次包括基础层和汇总层;汇总层是指该层次能够由其它一个或多个基础层次计算出来,建立所述业务***的若干逻辑表,将逻辑表的外键设置为指向某个维度或者某个维度的层次的字段,逻辑表的主键为逻辑表中一个取值唯一的字段或者多个取值唯一的字段组,建立物理表与逻辑表之间的映射关系。根据逻辑表以及按规则定义的逻辑数据查询语法,编写逻辑查询语句LSQL;根据所述的逻辑数据查询语句LSQL获取语句中的业务数据项,根据所述的业务数据项以及逻辑表与物理表之间的映射关系,将LSQL语句转化成基于物理表的SQL查询语句。
Description
技术领域
本发明涉及数据库,更具体地来说,特别涉及一种基于SQL的查询语言。
背景技术
结构化查询语言(Structured Query Language)简称SQL,是一种特殊目的的编程语言,是一种数据库查询和程序设计语言,用于存取数据以及查询、更新和管理关系数据库***;同时也是数据库脚本文件的扩展名。
结构化查询语言是高级的非过程化编程语言,允许用户在高层数据结构上工作。它不要求用户指定对数据的存放方法,也不需要用户了解具体的数据存放方式,所以具有完全不同底层结构的不同数据库***,可以使用相同的结构化查询语言作为数据输入与管理的接口。结构化查询语言语句可以嵌套,这使它具有极大的灵活性和强大的功能。
1986年10月,美国国家标准协会对SQL进行规范后,以此作为关系式数据库管理***的标准语言(ANSI X3.135-1986),1987年得到国际标准组织的支持下成为国际标准。不过各种通行的数据库***在其实践过程中都对SQL规范作了某些编改和扩充。所以,实际上不同数据库***之间的SQL不能完全相互通用。
应用
结构化查询语言SQL(Structured Query Language)是最重要的关系数据库操作语言,并且它的影响已经超出数据库领域,得到其他领域的重视和采用,如人工智能领域的数据检索,***软件开发工具中嵌入SQL的语言等。
支持标准
SQL是1986年10月由美国国家标准局(ANSI)通过的数据库语言美国标准,接着,国际标准化组织(ISO)颁布了SQL正式国际标准。1989年4月,ISO提出了具有完整性特征的SQL89标准,1992年11月又公布了SQL92标准,在此标准中,把数据库分为三个级别:基本集、标准集和完全集。
其他版本
各种不同的数据库对SQL语言的支持与标准存在着细微的不同,这是因为,有的产品的开发先于标准的公布,另外,各产品开发商为了达到特殊的性能或新的特性,需要对标准进行扩展。已有100多种遍布在从微机到大型机上的数据库产品SQL,其中包括DB2、SQL/DS、ORACLE、INGRES、SYBASE、SQLSERVER、DBASEIV、PARADOX、MICROSOFTACCESS等。
SQL语言基本上独立于数据库本身、使用的机器、网络、操作***,基于SQL的DBMS产品可以运行在从个人机、工作站到基于局域网、小型机和大型机的各种计算机***上,具有良好的可移植性。可以看出标准化的工作是很有意义的。早在1987年就有有识之士预测SQL的标准化是“一场革命”,是“关系数据库管理***的转折点”。数据库和各种产品都使用SQL作为共同的数据存取语言和标准的接口,使不同数据库***之间的互操作有了共同的基础,进而实现异构机、各种操作环境的共享与移植。
1974年,在IBM公司圣约瑟研究实验室研制的大型关系数据库管理***SYSTEM R中,使用SEQUEL语言(由BOYCE和CHAMBERLIN提出),后来在SEQUEL的基础上发展了SQL语言。SQL语言是一种交互式查询语言,允许用户直接查询存储数据,但它不是完整的程序语言,如它没有DO或FOR类似的循环语句,但它可以嵌入到另一种语言中,也可以借用VB、C、JAVA等语言,通过调用级接口(CALL LEVEL INTERFACE)直接发送到数据库管理***。SQL基本上是域关系演算,但可以实现关系代数操作。
语句结构
结构化查询语言包含6个部分:
一:数据查询语言(DQL:Data Query Language):
其语句,也称为“数据检索语句”,用以从表中获得数据,确定数据怎样在应用程序给出。保留字SELECT是DQL(也是所有SQL)用得最多的动词,其他DQL常用的保留字有WHERE,ORDER BY,GROUP BY和HAVING。这些DQL保留字常与其他类型的SQL语句一起使用。
二:数据操作语言(DML:Data Manipulation Language):
其语句包括动词INSERT,UPDATE和DELETE。它们分别用于添加,修改和删除表中的行。也称为动作查询语言。
三:事务处理语言(TPL):
它的语句能确保被DML语句影响的表的所有行及时得以更新。TPL语句包括BEGINTRANSACTION,COMMIT和ROLLBACK。
四:数据控制语言(DCL):
它的语句通过GRANT或REVOKE获得许可,确定单个用户和用户组对数据库对象的访问。某些RDBMS可用GRANT或REVOKE控制对表单个列的访问。
五:数据定义语言(DDL):
其语句包括动词CREATE和DROP。在数据库中创建新表或删除表(CREATE TABLE或DROP TABLE);为表加入索引等。DDL包括许多与人数据库目录中获得数据有关的保留字。它也是动作查询的一部分。
六:指针控制语言(CCL):
它的语句,像DECLARE CURSOR,FETCH INTO和UPDATE WHERE CURRENT用于对一个或多个表单独行的操作。
发展历史
在1970年代初,由IBM公司San Jose,California研究实验室的埃德加·科德发表将数据组成表格的应用原则(Codd’s Relational Algebra)。1974年,同一实验室的D.D.Chamberlin和R.F.Boyce对Codd’s Relational Algebra在研制关系数据库管理***System R中,研制出一套规范语言-SEQUEL(Structured English Query Language),并在1976年11月的IBM Journal of R&D上公布新版本的SQL(叫SEQUEL/2)。1980年改名为SQL。
1979年ORACLE公司首先提供商用的SQL,IBM公司在DB2和SQL/DS数据库***中也实现了SQL。
1986年10月,美国ANSI采用SQL作为关系数据库管理***的标准语言(ANSIX3.135-1986),后为国际标准化组织(ISO)采纳为国际标准。
1989年,美国ANSI采纳在ANSI X3.135-1989报告中定义的关系数据库管理***的SQL标准语言,称为ANSI SQL 89,该标准替代ANSI X3.135-1986版本。该标准为下列组织所采纳:
国际标准化组织(ISO),为ISO 9075-1989报告“Database Language SQL WithIntegrity Enhancement”
美国联邦政府,发布在The Federal Information Processing StandardPublication(FIPS PUB)127
目前(21世纪初期)主要的关系数据库管理***支持某些形式的SQL,大部分数据库打算遵守ANSI SQL89标准。
语言特点
1.一体化:SQL集数据定义DDL、数据操纵DML和数据控制DCL于一体,可以完成数据库中的全部工作。
2.使用方式灵活:它具有两种使用方式,即可以直接以命令方式交互使用;也可以嵌入使用,嵌入到C、C++、FORTRAN、COBOL、JAVA等主语言中使用。
3.非过程化:只提操作要求,不必描述操作步骤,也不需要导航。使用时只需要告诉计算机“做什么”,而不需要告诉它“怎么做”。
4.语言简洁,语法简单,好学好用:在ANSI标准中,只包含了94个英文单词,核心功能只用6个动词,语法接近英语口语。
语言缺点
对复杂的SQL查询,特别是多表关联查询的web***,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询。通过这些例子,SQL语言的问题暴露无遗。
原因是当要取出多个有关联表中的记录时,SQL采用连接语法来书写,其基本原理可以理解为将多个表中的记录先做完全叉乘(即笛卡尔积),再使用引用表的外键与被引用表的外键相等的过滤条件将叉乘出来的不必要的记录去除,从而得到最后的结果。如果有涉及N个表,则两两之间均有可能有关联,则可能书写出来的连接过滤条件会有N*(N-1)/2个,复杂度也是N2级别的,导致书写非常困难。表与表之间的耦合度也非常高,导致应用程序的局部维护修改都很困难。
发明内容
为了克服前述问题,本发明的目的在于提供一种基于SQL的查询语言。语法吸收了SQL的特点,利于学习,使用广泛,主要适用于数据库开发领域,降低数据表理解及书写的复杂度,改善业务***的数据结构的可理解性。
本发明提供的一种基于SQL的查询语言,使用方法为:
1.在抽取业务***中的各项维度时,还包括抽取各项维度所包含的层次,并确定各项维度的层次之间的计算关系;所述的各项维度的层次包括基础层和汇总层;所述的汇总层是指该层次能够由其它一个或多个基础层次计算出来。
2.建立所述业务***的若干逻辑表,将逻辑表的外键设置为指向某个维度或者某个维度的层次的字段,逻辑表的主键为逻辑表中一个取值唯一的字段或者多个取值唯一的字段组。
3.建立物理表与逻辑表之间的映射关系的具体方式为:
a)在物理表中选择与每个逻辑表相对应的基表,逻辑表中的每个逻辑字段都能够由所述的基表计算而来;
b)建立逻辑表的主键与基表主键之间的映射关系;特殊情况下,可能逻辑表的主键并不与基表的主键对应,但仍可以根据逻辑表所描述的数据逻辑建立其主键与基表主键的映射关系;
c)建立逻辑表中非主键逻辑字段由基表字段构成的表达式表示。
4.根据逻辑表以及按规则定义的逻辑数据查询语法,编写逻辑查询语句LSQL;
5.根据所述的逻辑数据查询语句LSQL获取语句中的业务数据项,根据所述的业务数据项以及逻辑表与物理表之间的映射关系,将LSQL语句转化成基于物理表的SQL查询语句。
如上所述的一种查询语言,其特征在于,可以跨平台、跨数据库进行开发应用。
如上所述的一种查询语言,其特征在于,本数据查询语言可以应用到任何业务***里面。
如上所述的一种查询语言,其特征在于,可根据本发明的原理进行其他形式的编写。
语法中定义的部分关键字列举如下:
SELECT T.x,…ON D#L,…FROM T WHERE…BY T.x AT D JOIN T…HAVING…
其中,SELECT、FROM、WHERE以及HAVING是SQL语句中的常用关键字,其含义与SQL语句中相同;JOIN、ON、BY以及AT是SQL中有的关键字但在LSQL赋予了新的意义和用法。
本发明中的实施例的LSQL语法中需要用到的参数及一些具体的逻辑查询语句的说明如下:
1)维(逻辑表的外键)的层用#表示,如K#L,表示维度为K,L为K的层,具体如:日期#年,日期#月,地区#国家,地区#省份
2)广义外键的字段可以直接用.操作符写出来,引用附表字段相当于本表附表字段在物理表中是另一个表的字段,不是FROM后面那个表的字段,是FROM表中外键字段指向表的字段,如果不用这种写法,就要写两个表的叉乘运算,要涉及两个表,写法很复杂,用广义外键的写法后,附表的字段就相当于是本表字段一样引用,变成只对一个表操作了,问题被简化了许多。例如:逻辑表的外键可以多层指出去,比如订单表的外键“客户”,指向客户表,客户表里的外键“所在地区”,那么“所在地区”就是订单表的广义外键。
如语句T.K.F中,T是表,K是外键,F是外键指向表的字段;具体的,如订单.客户.所在地区,订单表的外键客户指向客户表,客户表中的所在地区字段就是订单表的广义外键;
同样,语句T.K#L.F中,T是表,K是外键,L为K的层,F是外键指向表的字段;具体的,如客户.所在地区#省份.省份名称,客户表的外键即所在地区的省份层指向省份表,省份表中的身份名称字段就是客户表的广义外键。
3)选出数据项可以加上聚合计算,如T.SUM(F),T.COUNT(1)等
具体如:订单.sum(金额),客户.count(1)
SUM和COUNT也是SQL的关键字,就是求和和计数,订单.SUM(金额)就是对订单表的金额字段值求和,客户.COUNT(1)是对客户表计数,COUNT函数需要有个参数,本发明下述的实施例中用参数1表示,在2)和3)中操作符.是有区别的,操作符.之后是什么和前面是什么有关,.前面是表,则.之后就是本表的字段,这在SQL中也有约定,在LSQL也延用;若.前面是外键,则.后是外键指向表的字段,在SQL不支持这种写法,是本实施例的LSQL再约定的。
4)select关键字表示数据的来源;FROM关键字后可有多个表,表示数据从多个表中取出,多表之间用JOIN关键字连接,但没有表与表之间的关联描述项;
如语句select客户表.客户名称,表示数据取自客户表的客户名称字段;
语句:订单表.sum(金额)from订单表by客户join客户表,表示把客户名称和该客户的订单金额之和对应起来;订单表的金额按客户去分组合计,每个客户对应一个合计额,BY相当于SQL里的GROUP BY,这句SQL的SELECT子句中用到了两个表的字段,所有要再JOIN上另一个表;
5)BY关键字后是其前面表的分类汇总字段,必须是该表的广义外键,如省略则用该表的主键,如语句:
select回款表.sum(金额),订单表.sum(金额)from订单表by客户join回款表by客户,表示按客户统计回款金额和订单金额。
语句:select客户表.客户名称,订单表.sum(金额)from订单表by客户join客户表by客户ID(客户ID可省略,因为是客户表的主键),表示按客户ID列出客户名称和其订单金额合计。
6)ON关键字后的参数是目标汇总维度(及层),省略时使用所有表的BY的并集语句:select回款表.sum(金额),订单表.sum(金额)on年,客户from订单表by发货日期#年,客户join回款表by日期#年,客户;表示按客户和年度统计回款金额和订单金额
上述语句也可以写成
select回款表.sum(金额),订单表.sum(金额)
from订单表by发货日期#年,客户
join回款表by日期#年,客户
7)可以给ON后参数起别名,以便在BY后用AT关键字描述BY与ON的对应关系,未描述对应关系的将按维的类型自动对应:
select订单表.sum(金额)on年as发货年,年as签单年from订单表by发货日期#年at发货年,签单日期#年at签单年
表示按发货年和签单年统计订单金额。
8)WHERE是针对前面表的选出条件:
select回款表.sum(金额),订单表.sum(金额)on年,客户
from订单表where客户.所在地区#省份=’河北’by发货日期#年,客户
join回款表where客户.所在地区#省份=’河北’by日期#年,客户
该语句表示在6)中列举语句的基础上,只统计客户所在地区是河北省的数据
也可以写成:
select回款表.sum(金额),订单表.sum(金额)
on年,客户where客户.所在地区#省份=’河北’
from订单表by发货日期#年,客户
join回款表by日期#年,客户
9)HAVING是针对最终结果的选出条件
select sum(金额)
on年,客户
from订单表by发货日期#年,客户
Having sum(金额)>10000
假设原LSQL为:
select回款表.sum(金额),订单表.sum(金额)
on年,客户where客户.所在地区#省份.省份名称=’河北’
from订单表by发货日期#年,客户
join回款表by日期#年,客户
having订单表.sum(金额)>10000
将LSQL转换成物理SQL的步骤:
a)补齐省略的BY,ON,AT参数,BY省略用该表的主键,ON省略用BY的并集,AT省略则用同类型维依次对应
补齐后LSQL变成:
select回款表.sum(金额),订单表.sum(金额)
on年,客户where客户.所在地区#省份.省份名称=′河北′
from订单表by发货日期#年at年,客户at客户
join回款表by日期#年at年,客户at客户
having订单表.sum(金额)>10000
b)针对LSQL中FROM关键字后的每个表,找出LSQL中使用到的与之相关的数据项找出数据项如下加黑字体所示:
select回款表.sum(金额),订单表.sum(金额)
on年,客户where客户.所在地区#省份.省份名称=’河北’
from订单表by发货日期#年at年,客户at客户
join回款表by日期#年at年,客户at客户
having订单表.sum(金额)>10000
c)根据用到的数据项生成基于基表连接的SQL子查询
第一个子查询:
(SELECT YEAR(发货日期),客户,sum(金额)FROM订单表)
第二个子查询:
(SELECT YEAR(日期),客户,sum(金额)FROM回款表)
d)数据项中如果以广义外键方式有引用附表字段,则再递归地连接上附表的基表
第一个子查询:
(SELECT YEAR(订单表.发货日期),订单表.客户,sum(订单表.金额)FROM订单表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=订单表.客户)
第二个子查询:
(SELECT YEAR(回款表.日期),回款表.客户,sum(回款表.金额)FROM回款表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=回款表.客户)
e)拼上WHERE参数
第一个子查询:
(SELECT YEAR(订单表.发货日期),订单表.客户,sum(订单表.金额)FROM订单表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=订单表.客户and省份表.省份名称=’河北′)
第二个子查询:
(SELECT YEAR(回款表.日期),回款表.客户,sum(回款表.金额)FROM回款表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=回款表.客户and省份表.省份名称=’河北’)
f)判断表的BY参数是否是其主键,若否,则根据BY参数生成GROUP BY语句
第一个子查询:
(SELECT YEAR(订单表.发货日期),订单表.客户,sum(订单表.金额)FROM订单表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=订单表.客户and省份表.省份名称=’河北’GROUP BY YEAR(订单表.发货日期),订单表.客户)
第二个子查询:
(SELECT YEAR(回款表.日期),回款表.客户,sum(回款表.金额)FROM回款表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=回款表.客户and省份表.省份名称=’河北’GROUP BY YEAR(回款表.日期),回款表.客户)
g)将针对每个表产生的子查询根据ON和AT的对应关系连接(JOIN)起来
SELECT T_1.年,T_1.客户,T_2.回款金额,T_1.订单金额FROM
(SELECT YEAR(订单表.发货日期)年,订单表.客户,sum(订单表.金额)订单金额FROM订单表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=订单表.客户and省份表.省份名称=’河北’GROUP BY YEAR(订单表.发货日期),订单表.客户)T_1
join
(SELECT YEAR(回款表.日期)年,回款表.客户,sum(回款表.金额)回款金额FROM回款表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=回款表.客户and省份表.省份名称=’河北’GROUP BY YEAR(回款表.日期),回款表.客户)T_2
ON T_1.年=T_2.年AND T_1.客户=T_2.客户
h)拼上HAVING参数
SELECTT_1.年,T_1.客户,T_2.回款金额,T_1.订单金额
FROM
(SELECT YEAR(订单表.发货日期)年,订单表.客户,sum(订单表.金额)订单金额FROM订单表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=订单表.客户and省份表.省份名称=’河北’GROUP BY YEAR(订单表.发货日期),订单表.客户)T_1
join
(SELECT YEAR(回款表.日期)年,回款表.客户,sum(回款表.金额)回款金额FROM回款表,省份表,客户表where left(客户表.所在地区,2)=省份表.省份ID and客户表.客户ID=回款表.客户and省份表.省份名称=′河北’GROUP BY YEAR(回款表.日期),回款表.客户)T_2
ON T_1.年=T_2.年AND T_1.客户=T_2.客户
WHERE T_1.订单金额>10000
以上只是一个理论上的描述,实际实现过程中还会有各种优化的可能,以及进一步描述最终连接类型(FULL/LEFT等)的方式,但基本原理不会改变。本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的保护范围。
本发明的有益效果
将关系数据库RDB中网状的数据模型改造成总线结构,即每个逻辑表均与事先抽取出来的维度关联,而逻辑表之间不再有关联。关联数量与逻辑表数量匹配,复杂度是N级别的。这将极大改善业务***的数据结构可理解性。由于逻辑表之间不再有关联,从而降低表之间的耦合度,这样可以很方便地进行***的局部修改和升级及添加、删除某个子***。对于单外键指向的附表引用,LSQL可以简单地使用对象方式引用,将这种形式的多表关联简单看成是单表查询,极大降低理解和书写的复杂度。
下面结合附图和实施例对本发明进一步说明。
附图说明
图1为一种查询语言使用流程图;
图2为销售管理***需要的数据表;
图3为逻辑表外键的示意图;
图4为逻辑表主键的示意图。
具体实施方式
为了更好的说明本发明,首先对本具体实施方式中的一些缩略语和关键术语进行解释:
附表:以某个维(或其层)为主键的逻辑表
广义外键:递归定义为外键(或其层)或广义外键的附表的外键(或其层)
LSQL:Logical SQL,基于本发明体系设计的逻辑数据查询语言
本实施方式中的业务***为一个销售管理***,需要按地区和时间管理客户的订单和回款,该***中存在的业务数据表如图2所示。
首先,提取该销售管理***中所需要用到的各项维度,包括客户维、地区维、日期维和产品维,各维度包含的层次具体如下:
地区维:国家、省份、城市
日期维:年、月(包含年信息)、日(包含年月信息)
确定每个维度中基础层和汇总层之间的计算关系,具体如下:
日期维:年=int(月/100)年=year(日)月=year(日)*100+month(日)
如:年为2012,月为201208,日为2012-08-01
地区维:国家=left(省份,2)国家=left(城市,2)省份=left(城市,4)
如:国家为01,省份为0122,城市为01220315
其次,建立逻辑表以及逻辑表与维度(或者层)的关联关系,具体如下:
a)建立逻辑上描述业务数据的逻辑表,由若干逻辑字段构成
本实施例的销售管理***根据业务需要,建立的逻辑表及每个逻辑表所包含的逻辑字段具体如下:
订单表(订单id,客户,发货日期,签单日期,产品,金额)
回款表(回款id,客户,日期,金额)
客户表(客户ID,客户名称,所在地区)
城市表(城市id,城市名称)
省份表(省份id,省份名称)
国家表(国家id,国家名称)
产品表(产品ID,产品名称)
b)建立逻辑表与维度之间的关联关系
通过确定逻辑表的外键与主键,建立逻辑表与维度之间的关联。将逻辑表的外键设置为指向某个维度或者某个维度的层次的字段,逻辑表的主键为一个取值唯一的字段或者多个取值唯一的字段组。
逻辑表外键与主键的确定结果如图3和图4所示,图3与图4中只示出了订单表、回款表和客户表的外键及主键的确定结果,对于订单表,其外键为客户、签单日期、产品和发货日期,主键为订单ID;对于回款表,其外键是客户和日期,主键为回款ID;对于客户表,其外键为客户ID和所在地区,主键为客户ID。
再次,建立物理表与逻辑表之间的映射关系,具体如下:
a)从现成的数据库中取出物理表结构,物理表结构为:
order(orderId,customer,signDate,product,deliverDate,amount)
income(incomeId,customer,date,amount)
customer(customerID,customerName,area)
city(cityID,cityName)
province(provinceID,provinceName)
country(countryID,countryName)
prodnct(productID,productName)
为了区分物理表与逻辑表,逻辑表用中文描述,该步骤中的物理表用英文描述。
b)针对每个逻辑表,在物理表中选择若干主键相同的基表与之对应,确保逻辑表每个字段都能够由这些基表计算出来,本实施例中逻辑表与基表的对应关系如下:
order——>订单表income——>回款表customer——>客户表
city——>城市表province——>省份表country——>国家表
product——>产品表
c)建立逻辑主键与每个基表主键之间的映射关系
order.orderID——>订单表.订单ID
income.incomeID——>回款表.回款ID
customer.customerID——>客户表.客户ID
city.cityID——>城市表.城市ID
province.provinceID——>省份表.省份ID
country.countryID——>国家表.国家ID
product.productID——>产品表.产品ID
逻辑表的主键与基表主键之间是一一对应的关系,如逻辑订单表的主键订单ID与物理表order的orderID对应。
d)建立其它非主键逻辑字段与基表字段之间的计算关系,即为每个逻辑字段定义一个由基表字段构成的表达式,最常见的情况是逻辑字段直接对应某个基表字段。
本实施例中完成步骤c和步骤d后的结构如下表所示:
然后,设计逻辑查询语句LSQL;
最后,将LSQL做转换成数据库SQL执行。
Claims (5)
1.一种基于SQL的查询语言,其特征在于,包括:语法吸收了SQL的特点,主要适用于开发领域,降低数据表理解及书写的复杂度,改善业务***数据结构的可理解性。
2.如权利要求1所述的一种基于SQL的查询语言,其特征在于,步骤如下:
a.在抽取业务***中的各项维度时,还包括抽取各项维度所包含的层次,并确定各项维度的层次之间的计算关系;所述的各项维度的层次包括基础层和汇总层;所述的汇总层是指该层次能够由其它一个或多个基础层次计算出来;
b.建立所述业务***的若干逻辑表,将逻辑表的外键设置为指向某个维度或者某个维度的层次的字段,逻辑表的主键为逻辑表中一个取值唯一的字段或者多个取值唯一的字段组;
c.建立物理表与逻辑表之间映射关系的具体方式为:
1)在物理表中选择与每个逻辑表相对应的基表,逻辑表中的每个逻辑字段都能够由所述的基表计算而来;
2)建立逻辑表的主键与基表主键之间的映射关系;特殊情况下,可能逻辑表的主键并不与基表的主键对应,但仍可以根据逻辑表所描述的数据逻辑建立其主键与基表主键的映射关系;
3)建立逻辑表中非主键逻辑字段由基表字段构成的表达式表示。
d.根据逻辑表以及按规则定义的逻辑数据查询语法,编写逻辑查询语句LSQL;
e.根据所述的逻辑查询语句LSQL获取语句中的业务数据项,根据所述的业务数据项以及逻辑表与物理表之间的映射关系,将LSQL语句转化成基于物理表的SQL查询语句。
3.如权利要求1所述的一种基于SQL的查询语言,其特征在于,本数据查询语言可以跨平台、跨数据库进行开发应用。
4.如权利要求1所述的一种基于SQL的查询语言,其特征在于,本数据查询语言可以应用到任何业务***里面。
5.如权利要求1所述的一种基于SQL的查询语言,其特征在于,可根据本发明的原理进行其他形式的编写。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710302570.XA CN108804460A (zh) | 2017-05-03 | 2017-05-03 | 一种基于sql的查询语言 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710302570.XA CN108804460A (zh) | 2017-05-03 | 2017-05-03 | 一种基于sql的查询语言 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN108804460A true CN108804460A (zh) | 2018-11-13 |
Family
ID=64054203
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710302570.XA Pending CN108804460A (zh) | 2017-05-03 | 2017-05-03 | 一种基于sql的查询语言 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108804460A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109840256A (zh) * | 2019-03-05 | 2019-06-04 | 山东浪潮通软信息科技有限公司 | 一种基于业务实体的查询实现方法 |
CN110162544A (zh) * | 2019-05-30 | 2019-08-23 | 口碑(上海)信息技术有限公司 | 异构数据源数据获取方法及装置 |
CN111813804A (zh) * | 2019-04-11 | 2020-10-23 | 百度在线网络技术(北京)有限公司 | 一种数据查询方法、装置、电子设备及存储介质 |
-
2017
- 2017-05-03 CN CN201710302570.XA patent/CN108804460A/zh active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109840256A (zh) * | 2019-03-05 | 2019-06-04 | 山东浪潮通软信息科技有限公司 | 一种基于业务实体的查询实现方法 |
CN111813804A (zh) * | 2019-04-11 | 2020-10-23 | 百度在线网络技术(北京)有限公司 | 一种数据查询方法、装置、电子设备及存储介质 |
CN111813804B (zh) * | 2019-04-11 | 2023-08-15 | 百度在线网络技术(北京)有限公司 | 一种数据查询方法、装置、电子设备及存储介质 |
CN110162544A (zh) * | 2019-05-30 | 2019-08-23 | 口碑(上海)信息技术有限公司 | 异构数据源数据获取方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6374252B1 (en) | Modeling of object-oriented database structures, translation to relational database structures, and dynamic searches thereon | |
Groff et al. | SQL: the complete reference | |
US5734887A (en) | Method and apparatus for logical data access to a physical relational database | |
Elmasri | Fundamentals of database systems seventh edition | |
Narang | Database management systems | |
Navathe | Schema analysis for database restructuring | |
Rolland | The essence of databases | |
Agarwal et al. | Architecting object applications for high performance with relational databases | |
CN108804460A (zh) | 一种基于sql的查询语言 | |
Gorman | Database management systems: understanding and applying database technology | |
Yannakoudakis | The architectural logic of database systems | |
Laender et al. | A semantic comparison of the modelling capabilities of the ER and NIAM models | |
Kreines | Oracle SQL: the essential reference | |
Stonebraker et al. | The implementation of POSTGRES | |
Boulanger et al. | An approach to analyzing the information content of existing databases | |
Powell | Oracle high performance tuning for 9i and 10g | |
Wang et al. | Semantic heterogeneity in multidatabase systems: A review and a proposed meta-data structure | |
Lecluse et al. | Manipulation of structured values in object-oriented databases | |
Eze et al. | Database system concepts, implementations and organizations-a detailed survey | |
Mittra | Database performance tuning and optimization: using Oracle | |
Yannakoudakis et al. | Standard relational and network database languages | |
Thanuja et al. | Database Management Systems: An Introduction | |
Sathappan et al. | Database Management Systems | |
Rajiv | Database Management System (DBMS): A Practical Approach | |
Buchanan et al. | A database management system for the federal courts |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20181113 |
|
WD01 | Invention patent application deemed withdrawn after publication |