所谓离散性，是指集合的成员可以游离在集合之外存在并参与运算，游离成员还可以再组成新的集合。从离散性的解释上可以知道，离散性是针对集合而言的一种能力，离开集合概念单独谈离散性就没有意义了。
离散性是个很简单的特性，几乎所有支持结构（对象）的高级语言都天然支持，比如我们用Java时都可以把数组成员取出来单独计算，也可以再次组成新的数组进行集合运算（不过Java几乎没有提供集合运算类库）。
但是SQL的离散性却很差。
SQL体系中有记录的概念，但并没有显式的记录数据类型。单条记录被SQL作为只有一条记录的临时表处理，也就是个单成员的集合。而且，SQL从表（集合）中取出记录时总是复制出一条新记录，和原表中的记录已经没有关系了，这个特性被称为immutable。immutable特性有助于保证代码的正确性和简单性，但也会丧失离散性。
缺失离散性会带来代码的繁琐和效率的低下。
比如要计算张三和李四的年龄差和工资差，SQL要写成两句：
这不仅书写麻烦，而且要重复查询。
如果支持较好的离散性，我们可以写成这样：
查询结果可以游离在集合外独立存在，并可以反复使用。
immutable特性会要求每次运算都复制数据，这在只读的运算中还只是浪费时间和空间影响效率，但如果要改写数据时，造成的麻烦就严重得多。
比如我们想对业绩在前10%销售员再给予5%的奖励。一个正常思路是先把业绩在前10%的销售员找出来，形成一个中间集合，然后再针对这个集合的成员执行奖励5%的动作。但由于SQL缺乏离散性，immutable特性导致满足条件的记录再形成的集合和原记录是无关的，在中间结果集上做修改没有意义。这样就迫使我们要把整个动作写成一个语句，直接在原表中找到满足条件的记录再加以修改，而前10%这种条件并不容易简单地在WHERE子句中写出来，这又会导致复杂的子查询。这还只是个简单例子，现实应用中比这复杂的条件比比皆是，用子查询也很难写出，经常采用的办法则是先把满足条件的记录的主键计算出来，再用这些主键到原表中遍历找到原记录去修改，代码繁琐且效率极为低下。
如果语言支持离散性，我们就可以执行上述思路了：
从上面两个简单例子可以看出，缺失离散性会加剧分步计算的困难，immutable特性会降低性能并占用空间。当然，离散性的问题还不止于此。
不能用原集合的成员构成新集合再进行计算，SQL在做分组时无法保持分组子集，必须强迫聚合，作为集合化语言，SQL的集合化并不彻底。没有游离记录及其集合的表示方法，只能用传统的外键方案表示数据之间的关联关系，写出的代码既繁琐又难懂，而且运算性能还差，缺乏离散性的SQL无法采用直观的引用机制描述关联。特别地，没有离散性的支持，SQL很难描述有序计算，有序计算是离散性和集合化的典型结合产物，成员的次序在集合中才有意义，这要求集合化，有序计算时又要将每个成员与相邻成员区分开，会强调离散性。
这些具体内容我们会在后续文档中逐步详细说明。我们要从理论上改进SQL（或者更合适的说法是关系代数），主要工作就是在保持集合化的基础上引入离散性，从而解决上述问题，让新的语言能够同时拥有SQL和Java的优点。
清华大学计算机硕士，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016年，荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”；2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。
《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。