精华内容
下载资源
问答
  • 金融数据库分层结构

    2020-03-02 22:32:08
    在一个数据库中,各个层体现为数据库中的不同用户。 数据缓冲层 : 完成将来自源数据层的数据向数据仓库的抽取、转换和加载。该层为数据仓库数据流向的主要环节。 从源数据层抽取过来的数据通过FTP协议传送到...

    一个完整的金融系统数据平台按照业务线条依次分为:
    源系统→SDB(数据缓冲层)→ODB(数据贴源层)→PDB(整合模型层)→COD(共性加工层)→MDB(应用集市层)

    特点
    MDB应用集市层 应用集市层是对共性加工层中数据的进一步加工和重组,为应用的数据访问提供数据支持
    按日切片
    CDB共性加工层 通过对主题模型层中的数据按照业务经验进行适当的提炼、汇总,向用户提供各种服务
    对主题模型层中的数据进行拉链、快照等算法处理
    PDB整合模型层 按照teradata十大主题将贴源层数据分类整合
    对ODB数据贴源层中的数据进行拉链、快照等算法处理
    ODB数据贴源层 保留较长历史数据,与源数据结构保持一致。为整合模型层、共性加工层数据清洗、转换做准备
    对SDB技术缓冲层中的数据进行拉链、快照等算法处理
    SDB技术缓冲层 与业务源的数据结构一一对应,它是数据存储的临时区域
    通过sqlldr将源系统产生的数据批量导入到SDB中
    源系统 作为数据导入层的数据抽取源,为整个数据仓库提供原始数据,生成txt文件数据

    在一个数据库中,各个层体现为数据库中的不同用户。

    数据缓冲层
    完成将来自源数据层的数据向数据仓库的抽取、转换和加载。该层为数据仓库数据流向的主要环节。
    从源数据层抽取过来的数据通过FTP协议传送到指定机器的指定目录,采用ORALCLE SQLLDR的方式向数据仓库加载数据,整个ETL流程管理采用调度工具调用PERL+SQL脚本完成。
    数据缓冲层存储的数据与业务源的数据结构一一对应,但是保存时间不是长期保存。在规定的储存空间满后,删除替换早期存储的数据。

    数据贴源层
    从技术缓冲层进行拉链算法 ,增量追加或全量数据。数据缓冲层存储的数据与业务源的数据结构仍然是一一对应的。与缓冲层的区别是,贴源层的所有数据和历史数据要求长期保存。如果规定的存储空间满后,不会删除最早的旧数据而是增加存储容量。

    整合模型层
    整合模型层将数据贴源层的数据按照teradata十大主题管理数据。

    teradata十大主题
    以银行金融为例按照这种分类方法处理数据贴源层的数据之后,有利于ETL人员下一步对数据的提取 。经过整合模型层对源数据的清洗转换整合,可以减少业务人员的工作负担,使上层数据更干净可视性更好。但会增加存储成本和维护成本等。

    共性加工层
    通过对整合模型层中的数据进行适当的提炼、汇总,向用户提供包括报表服务、查询服务、数据挖掘服务和中间件服务等多种服务应用。该层为用户对中央数据的访问提供各种方式的服务,从而实现访问方式的多样化和信息存取的透明化。
    特点: 全局考虑,提炼需求共性,多层次设计,多种数据粒度,侧重业务理解,蕴含丰富的业务规则。

    应用集市层
    用户访问数据源的方式都是通过应用集市层来实现各种应用的展现与定制,应用集市层是对共性加工层中数据的进一步加工和重组,为应用的数据访问提供数据支持。
    特点:面向应用,形式各异,各自独立,按需定制,满足特定业务的需求。

    *业务用户层:
    用户层包括各种最终用户。按照用户使用数据平台的方式和特点,可以划分为一般业务人员、业务分析人员、决策人员等。这些用户分散在各个业务部门,根据用户不同的行政组织结构和业务职能,可对用户进行分组,这些用户以及用户组的划分、包括用户权限的设定都将定义在访问控制层的用户安全管理体系中。
    【引用】
    不同类型项目的数据层次建议:
    ODS:
    技术缓冲层:视加工过程是否需要而定,非必须,但一般会有同源设计,基本不做处理
    近源模型层:必须,是ODS核心模型层简单处理
    整合模型层:视项目具体需求而定,非必须建设层次只针对必须整合且比较基础的部分才考虑建设此层
    共性加工层:视项目具体需求而定,非必须建设层次
    应用集市层:视项目具体需求而定,分仓内仓外两种建设策略
    EDW:
    技术缓冲层:视加工过程是否需要而定,非必须,但一般会有同源设计,基本不做处理
    近源模型层:视项目具体需求而定,非必须建设层次
    整合模型层:必须,是EDW核心模型层整合设计
    共性加工层:建议保留兼顾业务需求和数据处理性能双方需求
    应用集市层:视具体情况而定,分仓内仓外两种建设策略按单个应用分别建设

    展开全文
  • 基于结构层次化设计的思想我们经常须要对这一系列操作进行分层设计。 各层的主要职责。以及发生异常怎样处理。是向上继续抛出,还是在该层对异常做转换等处理,以及事务中发生异常时缓存的处理等须要一些思考。 以...

    在持久化数据的读写操作中经常要涉及到 数据库与缓存 的操作,同一时候因为业务须要经常要对多表进行事务操作。基于结构层次化设计的思想我们经常须要对这一系列操作进行分层设计。

    各层的主要职责。以及发生异常怎样处理。是向上继续抛出,还是在该层对异常做转换等处理,以及事务中发生异常时缓存的处理等须要一些思考。

    以个人的经验为例:
    经常将持久化操作分为3层:dao层,manager层,service层
    当中
    dao层:直接进行数据库读写操作。


    发生异常时,向上抛,调用方能够依据捕获的异常信息。找到db放生错误的原因(sql语法错误 还是 反复插入同一主键等)

    public List<Something> queryList(SomethingQuery SomethingQuery) throws DAOException;

    manager层:改成将配合缓存进行数据库的读写操作。
    我的做法

    insert:
         insertDB(something)    //直接操作db
    query:
         something = getSomethingFromCache   //首先读缓存,不存在时读db
         if(something == NULL) {
             something = getSomethingFromDB
             putSomethingToDB(something)
         }
         return something
    update:
        updateDB(something)    //更新db。同一时候失效缓存中 脏数据
        invalidCache(something)
    delete:
         deleteDB(something)   //删除db中数据。同一时候失效缓存中 脏数据
         invalidCache(something)

    该层发生异常时,对外抛出,不曾不作处理。我之前的做法,在该层多异常作处理。如发生异常时 我就返回null, 这种弊端在于 调用方对null无法做进一步的区分(是发生异常 还是 db与缓存中 均不存在 导致返回null),从而使容错性能下降,比如假设能是异常导致的,则能够进行多次尝试。而当数据不存在时。就须要马上返回作处理了。毕竟manager层相对来说层级较低,说要向上层调用方提供尽可能多的信息,方便做容错等错里。

    service层:在该层经常会依据业务的须要做多表的事务操作。

    update:
                doInTransaction(TransactionStatus status) {
                    try {
                        Long tableId1 = table1.insert(something1);
                        Long tableId2 = table2.insert(something2);
                    } catch (Exception e) {
                        status.setRollbackOnly();
                    }
                }

    该层发生异常时,经常会依据业务需求作转换,比如对于查询失败操作,能够将失败的详细信息一并返回调用方,便于问题排查。

    queryResult.isSuccess = false;
    
    queryResult.msg = “db error”;
    queryResult.msg = “不存在”;

    转载于:https://www.cnblogs.com/jzssuanfa/p/7133623.html

    展开全文
  • 数据库分层设计概述

    2020-11-28 10:02:40
    一、文章主题 本文主要讲解数据仓库的一个重要环节:如何设计数据分层!其它关于数据仓库的内容可参考之前的文章。 【漫谈数据仓库】 如何优雅地设计数据分层 ...二、文章结构 最初在做数据仓库的时候遇到了很多坑,由于

    一、文章主题

    本文主要讲解数据仓库的一个重要环节:如何设计数据分层!其它关于数据仓库的内容可参考之前的文章。

    【漫谈数据仓库】 如何优雅地设计数据分层

    本文对数据分层的讨论适合下面一些场景,超过该范围场景 or 数据仓库经验丰富的大神就不必浪费时间看了。

    数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务。
    数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得。
    各种重复计算,严重浪费了计算资源,需要优化性能。
    二、文章结构

    最初在做数据仓库的时候遇到了很多坑,由于自身资源有限,接触数据仓库的时候,感觉在互联网行业里面的数据仓库成功经验很少,网上很难找到实践性比较强的资料。而那几本经典书籍里面又过于理论,折腾起来真是生不如死。还好现在过去了那个坎,因此多花一些时间整理自己的思路,帮助其他的小伙伴少踩一些坑。文章的结构如下:

    为什么要分层?这个问题被好几个同学质疑过。因此分层的价值还是要说清楚的。
    分享一下经典的数据分层模型,以及每一层的数据的作用和如何加工得来。
    分享两个数据分层的设计,通过这两个实际的例子来说明每一层该怎么存数据。
    给出一些建议,不是最好的,但是可以做参考。
    0x01 为什么要分层

    我们对数据进行分层的一个主要原因就是希望在管理数据的时候,能对数据有一个更加清晰的掌控,详细来讲,主要有下面几个原因:

    清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。
    数据血缘追踪:简单来讲可以这样理解,我们最终给业务诚信的是一能直接使用的张业务表,但是它的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确地定位到问题,并清楚它的危害范围。
    减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。
    把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。
    屏蔽原始数据的异常。
    屏蔽业务的影响,不必改一次业务就需要重新接入数据。
    数据体系中的各个表的依赖就像是电线的流向一样,我们都希望它是规整、流向清晰、便于管理的,如下图:

    【漫谈数据仓库】 如何优雅地设计数据分层

    但是,最终的结果大多却是依赖复杂、层级混乱,想梳理清楚一张表的声称途径会比较困难,如下图:

    【漫谈数据仓库】 如何优雅地设计数据分层

    0x02 怎样分层

    一、理论

    我们从理论上来做一个抽象,可以把数据仓库分为下面三个层,即:数据运营层、数据仓库层和数据产品层。

    【漫谈数据仓库】 如何优雅地设计数据分层

    ODS 全称是 Operational Data Store,操作数据存储.“面向主题的”,数据运营层,也叫ODS层,是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的 ETL 之后,装入本层。本层的数据,总体上大多是按照源头业务系统的分类方式而分类的。但是,这一层面的数据却不等同于原始数据。在源数据装入这一层时,要进行诸如去噪(例如有一条数据中人的年龄是 300 岁,这种属于异常数据,就需要提前做一些处理)、去重(例如在个人资料表中,同一 ID 却有两条重复数据,在接入的时候需要做一步去重)、字段命名规范等一系列操作。
    数据仓库层(DW),是数据仓库的主体.在这里,从 ODS 层中获得的数据按照主题建立各种数据模型。这一层和维度建模会有比较深的联系,可以多参考一下前面的几篇文章。
    数据产品层(APP),这一层是提供为数据产品使用的结果数据
    在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、Mysql 等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。

    如我们经常说的报表数据,或者说那种大宽表,一般就放在这里。

    二、技术实践

    这三层技术划分,相对来说比较粗粒度,后面我们会专门细分一下。在此之前,先聊一下每一层的数据一般都是怎么流向的。这里仅仅简单介绍几个常用的工具,侧重中开源界主流。

    1. 数据来源层→ ODS层

    这里其实就是我们现在大数据技术发挥作用的一个主要战场。 我们的数据主要会有两个大的来源:

    业务库,这里经常会使用 Sqoop 来抽取,比如我们每天定时抽取一次。在实时方面,可以考虑用 Canal 监听 Mysql 的 Binlog,实时接入即可。

    埋点日志,线上系统会打入各种日志,这些日志一般以文件的形式保存,我们可以选择用 Flume 定时抽取,也可以用用 Spark Streaming 或者 Storm 来实时接入,当然,Kafka 也会是一个关键的角色。

    其它数据源会比较多样性,这和具体的业务相关,不再赘述。

    【漫谈数据仓库】 如何优雅地设计数据分层

    注意: 在这层,理应不是简单的数据接入,而是要考虑一定的数据清洗,比如异常字段的处理、字段命名规范化、时间字段的统一等,一般这些很容易会被忽略,但是却至关重要。特别是后期我们做各种特征自动生成的时候,会十分有用。后续会有文章来分享。

    1. ODS、DW → App层

    这里面也主要分两种类型:

    每日定时任务型:比如我们典型的日计算任务,每天凌晨算前一天的数据,早上起来看报表。 这种任务经常使用 Hive、Spark 或者生撸 MR 程序来计算,最终结果写入 Hive、Hbase、Mysql、Es 或者 Redis 中。
    实时数据:这部分主要是各种实时的系统使用,比如我们的实时推荐、实时用户画像,一般我们会用 Spark Streaming、Storm 或者 Flink 来计算,最后会落入 Es、Hbase 或者 Redis 中。
    0x03 举个例子

    网上的例子很多,就不列了,只举个笔者早期参与设计的数据分层例子。分析一下当初的想法,以及这种设计的缺陷。上原图和内容。

    当初的设计总共分了 6 层,其中去掉元数据后,还有5层。下面分析一下当初的一个设计思路。

    【漫谈数据仓库】 如何优雅地设计数据分层

    缓冲层(buffer)

    概念:又称为接口层(stage),用于存储每天的增量数据和变更数据,如Canal接收的业务变更日志。
    数据生成方式:直接从kafka接收源数据,需要业务表每天生成update,delete,inseret数据,只生成insert数据的业务表,数据直接入明细层
    讨论方案:只把canal日志直接入缓冲层,如果其它有拉链数据的业务,也入缓冲层。
    日志存储方式:使用impala外表,parquet文件格式,方便需要MR处理的数据读取。
    日志删除方式:长久存储,可只存储最近几天的数据。讨论方案:直接长久存储
    表schema:一般按天创建分区
    库与表命名。库名:buffer,表名:初步考虑格式为:buffer日期业务表名,待定。
    明细层(ODS, Operational Data Store,DWD: data warehouse detail)

    概念:是数据仓库的细节数据层,是对STAGE层数据进行沉淀,减少了抽取的复杂性,同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式,将各个专业数据进行集中,明细层跟stage层的粒度一致,属于分析的公共资源
    数据生成方式:部分数据直接来自kafka,部分数据为接口层数据与历史数据合成。
    canal日志合成数据的方式待研究。

    讨论方案:canal数据的合成方式为:每天把明细层的前天全量数据和昨天新数据合成一个新的数据表,覆盖旧表。同时使用历史镜像,按周/按月/按年 存储一个历史镜像到新表。
    日志存储方式:直接数据使用impala外表,parquet文件格式,canal合成数据为二次生成数据,建议使用内表,下面几层都是从impala生成的数据,建议都用内表+静态/动态分区。
    日志删除方式:长久存储。
    表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    库与表命名。库名:ods,表名:初步考虑格式为ods日期业务表名,待定。
    旧数据更新方式:直接覆盖
    轻度汇总层(MID或DWB, data warehouse basis)

    概念:轻度汇总层数据仓库中DWD层和DM层之间的一个过渡层次,是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂的清洗,处理包含,如根据PV日志生成的会话数据)。轻度综合层与DWD的主要区别在于二者的应用领域不同,DWD的数据来源于生产型系统,并未满意一些不可预见的需求而进行沉淀;轻度综合层则面向分析型应用进行细粒度的统计和沉淀
    数据生成方式:由明细层按照一定的业务需求生成轻度汇总表。明细层需要复杂清洗的数据和需要MR处理的数据也经过处理后接入到轻度汇总层。
    日志存储方式:内表,parquet文件格式。
    日志删除方式:长久存储。
    表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    库与表命名。库名:dwb,表名:初步考虑格式为:dwb日期业务表名,待定。
    旧数据更新方式:直接覆盖
    主题层(DM,data market或DWS, data warehouse service)

    概念:又称数据集市或宽表。按照业务划分,如流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。
    数据生成方式:由轻度汇总层和明细层数据计算生成。
    日志存储方式:使用impala内表,parquet文件格式。
    日志删除方式:长久存储。
    表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    库与表命名。库名:dm,表名:初步考虑格式为:dm日期业务表名,待定。
    旧数据更新方式:直接覆盖
    应用层(App)

    概念:应用层是根据业务需要,由前面三层数据统计而出的结果,可以直接提供查询展现,或导入至Mysql中使用。
    数据生成方式:由明细层、轻度汇总层,数据集市层生成,一般要求数据主要来源于集市层。
    日志存储方式:使用impala内表,parquet文件格式。
    日志删除方式:长久存储。
    表schema:一般按天创建分区,没有时间概念的按具体业务选择分区字段。
    库与表命名。库名:暂定apl,另外根据业务不同,不限定一定要一个库。
    旧数据更新方式:直接覆盖。
    0x04 如何更优雅一些

    前面提到的一种设计其实相对来讲已经很详细了,但是可能层次会有一点多,而且在区分一张表到底该存放在什么位置的时候可能还有不小的疑惑。我们在这一章里再设计一套数据仓库的分层,同时在前面的基础上加上维表和一些临时表的考虑,来让我们的方案更优雅一些。

    下图,做了一些小的改动,我们去掉了上一节的Buffer层,把数据集市层和轻度汇总层放在同一个层级上,同时独立出来了维表和临时表。

    【漫谈数据仓库】 如何优雅地设计数据分层

    这里解释一下DWS、DWD、DIM和TMP的作用。

    DWS:轻度汇总层,从ODS层中对用户的行为做一个初步的汇总,抽象出来一些通用的维度:时间、ip、id,并根据这些维度做一些统计值,比如用户每个时间段在不同登录ip购买的商品数等。这里做一层轻度的汇总会让计算更加的高效,在此基础上如果计算仅7天、30天、90天的行为的话会快很多。我们希望80%的业务都能通过我们的DWS层计算,而不是ODS。
    DWD:这一层主要解决一些数据质量问题和数据的完整度问题。比如用户的资料信息来自于很多不同表,而且经常出现延迟丢数据等问题,为了方便各个使用方更好的使用数据,我们可以在这一层做一个屏蔽。
    DIM:这一层比较单纯,举个例子就明白,比如国家代码和国家名、地理位置、中文名、国旗图片等信息就存在DIM层中。
    TMP:每一层的计算都会有很多临时表,专设一个DWTMP层来存储我们数据仓库的临时表。
    0x05 问答

    有朋友问了一些问题,有一些之前的确没讲清楚,补到这里。

    问答一: dws 和 dwd 的关系

    问:dws 和dwd 是并行而不是先后顺序?

    答:并行的,dw 层

    问:那其实对于同一个数据,这两个过程是串行的?

    答:dws 会做汇总,dwd 和 ods 的粒度相同,这两层之间也没有依赖的关系

    问:对呀,那这样 dws 里面的汇总没有经过数据质量和完整度的处理,或者单独做了这种质量相关的处理,为什么不在 dwd 之上再做汇总呢?我的疑问其实就是,dws的轻度汇总数据结果,有没有做数据质量的处理?

    答:ods 直接到 dws 就好,没必要过 dwd,我举个例子,你的浏览商品行为,我做一层轻度汇总,就直接放在 dws 了。但是你的资料表,要从好多表凑成一份,我们从四五份个人资料表中凑出来了一份完整的资料表放在了 dwd 中。然后在 app 层,我们要出一张画像表,包含用户资料和用户近一年的行为,我们就直接从dwd中拿资料, 然后再在 dws 的基础上做一层统计,就成一个app表了。当然,这不是绝对,dws 和 dwd 有没有依赖关系主要看有没有这种需求。

    问答二: ods 和 dwd 的区别

    问:还是不太明白 ods 和 dwd 层的区别,有了 ods 层后感觉 dwd 没有什么用了。

    答:嗯,我是这样理解的,站在一个理想的角度来讲,如果 ods 层的数据就非常规整,基本能满足我们绝大部分的需求,这当然是好的,这时候 dwd 层其实也没太大必要。 但是现实中接触的情况是 ods 层的数据很难保证质量,毕竟数据的来源多种多样,推送方也会有自己的推送逻辑,在这种情况下,我们就需要通过额外的一层 dwd 来屏蔽一些底层的差异。

    问:我大概明白了,是不是说 dwd 主要是对 ods 层做一些数据清洗和规范化的操作,dws 主要是对 ods 层数据做一些轻度的汇总?

    答:对的,可以大致这样理解。

    问答三:app 层是干什么的?

    问:感觉数据集市层是不是没地方放了,各个业务的数据集市表是应该在 dwd 还是在 app?

    答:这个问题不太好回答,我感觉主要就是明确一下数据集市层是干什么的,如果你的数据集市层放的就是一些可以供业务方使用的宽表表,放在 app 层就行。如果你说的数据集市层是一个比较泛一点的概念,那么其实 dws、dwd、app 这些合起来都算是数据集市的内容。

    问:那存到 Redis、ES 中的数据算是 app层吗?

    答:算是的,我个人的理解,app 层主要存放一些相对成熟的表,能供业务侧使用的。这些表可以在 Hive 中,也可以是从 Hive 导入 Redis 或者 ES 这种查询性能比较好的系统中。

    0xFF 总结

    数据分层是数据仓库非常重要的一个环节,它决定的不仅仅是一个层次的问题,还直接影响到血缘分析、特征自动生成、元数据管理等一系列功能的建设。因此适于尽早考虑。

    另外,每一层的名字不必太过在意,自己按照喜好就好。

    本文分享了笔者自己对数据仓库的一些理解和想法,不一定准确也不一定通用,但是可以作为一个参考的思路。有什么问题欢迎多交流。

    展开全文
  • 数据库分层数据现实方法

    千次阅读 2015-12-10 17:04:16
    分层数据 分层数据的每项(除根项)只有一个父项和零个或多个子项的数据集合。 分层数据存在于许多基于数据库的...邻接表模型数据库结构:+--------+----------------------+--------------+ | id | name | parent_id

    分层数据

    • 分层数据的每项(除根项)只有一个父项和零个或多个子项的数据集合。
    • 分层数据存在于许多基于数据库的应用程序中,包括论文和邮件列表中的分类、组织层级关系、内容管理系统的分类、产品分类。

    邻接表模型

    数据库中结构:

    +--------+----------------------+--------------+
    |          id | name            | parent_id    |
    +-------------+-----------------+--------------+
    |           1 | 智慧学校          |     NULL    |
    |           2 | 广东省教育厅       |      1      |
    |           3 | 广州市教育厅       |      2      |
    |           4 | 东莞市教育厅       |      2      |
    |           5 | 佛山市教育厅       |      2      |
    |           6 | 荔湾区华侨小学     |      3      |
    |           7 | 湖南省教育厅       |      1      |
    |           8 | 长沙市教育厅       |      7      |
    |           9 | 湘潭市教育厅       |      7      |
    |         10  | 张家界市教育厅     |      7      |
    +-------------+----------------------+--------+

    优点:
    实现简单,能直观看到直接父子关系。
    缺点:
    当要检索某节点下所有子孙节点时,只能一层一层递归查询。

    orcal中实现子孙节点查找:
    SELECT * FROM unit t CONNECT BY prior t.parent_id=t.id start with t.parent_id = 1
    mysql使用函数实现(使用函数形式):

    CREATE FUNCTION getChildLst(id INT)
      RETURNS varchar(1000) CHARSET utf8
    BEGIN 
           DECLARE sTemp VARCHAR(1000); 
           DECLARE sTempChd VARCHAR(1000); 
    
           SET sTemp = '$'; 
           SET sTempChd =cast(rootId as CHAR); 
    
           WHILE sTempChd is not null DO 
             SET sTemp = concat(sTemp,',',sTempChd); 
             SELECT group_concat(id) INTO sTempChd FROM emp where FIND_IN_SET(parentId,sTempChd)>0; 
           END WHILE; 
           RETURN substr(sTemp,3); 
         END

    看上面的语句是全表扫描,没有走索引。一些数据量比较大的表,查询就很慢。

    前缀编码模型

    数据库结构

    +-------------+-----------------+--------+
    |          id | name             | code |
    +--------+----------------------+--------+
    |           1 | Seewo智慧学校     |  001 |
    |           2 | 广东省教育厅       |  001001 |
    |           3 | 广州市教育厅       |  001001001 |
    |           4 | 东莞市教育厅       |  001001002 |
    |           5 | 佛山市教育厅       |  001001003 |
    |           6 | 荔湾区华侨小学     |  001001001001 |
    |           7 | 湖南省教育厅       |  001002 |
    |           8 | 长沙市教育厅       |  001002001 |
    |           9 | 湘潭市教育厅       |  001002002 |
    |          10 | 张家界市教育厅      | 001002003 |
    +-------------+----------------------+--------+

    节点编码:为当前记录行的编码(内部编码),它的所有直接下级记录行的编码都是以它为依据进行扩展。
    优点:
    使用like语句即可查出其所有子孙节点的记录集。
    缺点:
    固定长度编码限制了子节点的个数,层级不明显,查询直系亲属节点麻烦。
    每层的节点个数受编码长度限制

    改进的前缀编码模型

    数据库结构

    +--------+------------------+----------------+--------------+--------------+
    |     id | name             | parent_id      | code         |  childMaxNum |
    +--------+------------------+----------------+--------------+--------------+
    |      1 | Seewo智慧学校     |     NULL        |  1.         |      2        |
    |      2 | 广东省教育厅       |      1          |  1.1.       |      3        |
    |      3 | 广州市教育厅       |      2          |  1.1.1.     |      1        |
    |      4 | 东莞市教育厅       |      2          |  1.1.2.     |      0        |
    |      5 | 佛山市教育厅       |      2          |  1.1.3.     |      0        |
    |      6 | 荔湾区华侨小学     |      3          |   1.1.1.1.  |      0        |
    |      7 | 湖南省教育厅       |      1          |  1.2.       |      3        |
    |      8 | 长沙市教育厅       |      7          |  1.2.1.     |      0        |
    |      9 | 湘潭市教育厅       |      7          |  1.2.2.     |      0        |
    |     10 | 张家界市教育厅     |      7          | 1.2.3.       |      0        |
    +--------+-------------------+---------------+--------------+--------------+

    改进的前缀编码模型中添加了直系父节点id的parent_id,和当前子节点分配最大数childMaxNum(记录了当前已分配的数字),前缀编码code使用特殊符号区分节点的层次。
    查找子孙节点sql:
    select * from unit where code like ‘1.1.%’

    嵌套集合模型

    模型图:
    嵌套集合模型图
    使用左值和右值来表现嵌套集合模型中数据的分层特性。
    优点:
    所有子孙节点的左右值都在父节点的左右值范围内,能快速查找出一棵子树,且能快速判断是否含有子节点。
    缺点:
    1、当增加删除一个节点时,需要更新其他节点的左右值。
    2、层级不明显。

    二叉树模型

    这里写图片描述
    把这种层级结构变换为二叉树模型,变换规则,某节点A的左边第一个子节点B作为A左子节点,B右边第一个兄弟节点C作为B的右子节点,如果C右边还有兄弟节点D,则把D作为C的右子节点,如此类推。最后变换为下图:
    这里写图片描述
    每个节点的编码以一维数组存放二叉树的方式进行编码

    +-------------+-----------------+----------+
    |          id | name            | location |
    +--------+----------------------+----------+
    |           1 | Seewo智慧学校     |  1      |
    |           2 | 广东省教育厅       |  2      |
    |           3 | 广州市教育厅       |  4      |
    |           4 | 东莞市教育厅       |  9      |
    |           5 | 佛山市教育厅       |  19     |
    |           6 | 荔湾区华侨小学     |   8     |
    |           7 | 湖南省教育厅       |  5      |
    |           8 | 长沙市教育厅       |  10     |
    |           9 | 湘潭市教育厅       |  21     |
    |         10 | 张家界市教育厅      | 43      |
    +-------------+-----------------+---------+

    MongoDB实现

    使用非关系型数据库优点可以快速的查找

    { id"1",   name:"Seewo智慧学校", ancestors:[],     parent:null }
    { id"2", name:"广东省教育厅",  ancestors:["1"], parent:"1" }
    { id"3", name:"广州市教育厅 ",  ancestors:["1","2"], parent:"2" }
    { id"4", name:"东莞市教育厅",  ancestors:["1","2"], parent:"2" }
    { id"5", name:"佛山市教育厅",  ancestors:["1","2"], parent:"2" }
    { id"6", name:"荔湾区华侨小学",  ancestors:["1","2","3"], parent:"3" }
    { id"7", name:"湖南省教育厅",  ancestors:["1"], parent:"1" }
    { id"8", name:"长沙市教育厅",  ancestors:["1","8"], parent:"7" }
    { id"9", name:"湘潭市教育厅",  ancestors:["1","8"], parent:"7" }
    { id"10", name:"张家界市教育厅",  ancestors:["1","8"], parent:"7" }

    查找id=1的所有子孙节点:find({ancestors:”1”})

    展开全文
  •  数据库设计的三大范式:为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库,必须...
  • 数据库调优分层思想1.调优策略1)*号的处理(只提取必要字段,减少流量)最好是用,有用的字段,减少流量。表结构会改变,增加或者减少某列,如果*号全部查询出来 会造成代码逻辑错误。2)大SQL(拆分,逐步缩小结果集)大...
  • 首先,有三个实体对象User,Student, Teacher其中三者共同的属性是name,password,fullname,均定义在User中,Student和Teacher继承User用每个类分层的方式进行mapping映射,只需要用到一个表userinfo就可以描述以上...
  • 在这篇文章里,开始介绍MySQL数据库的逻辑分层。通过本文的介绍,可以大致了解到MySQL的语句从客户端发出请求后,在服务器经历了怎样的过程。有助于后面MySQL优化的加深理解。MySQL逻辑分层一般来说,MySQL逻辑可...
  • 一、数据库设计对于多级目录的设计,最简单直接的方式,可以直接把目录的名称和内容等相关信息放到一个表里,如何区分顶级目录和子目录是设计的关键。思想:可以把目录树看作是一个具有多个根节点的树状结构,子目录...
  • 不管数据库什么操作,都是先连接数据库,所以我们可以把连接数据库 // 封装成为内部函数 function _connectDB(callback) { // 先执行_connectDB函数体,决定了函数什么时候怎么执行 var url = settings....
  • 分层结构

    2021-03-22 15:34:15
    分层结构 Java项目分层结构 * Config:所有的配置,用于存放Spring Boot相关的配置类,包括启动类。 * Controller:请求入口,所有请求的入口,前后端交互的入口(前端调用和后端的入口)。 在Spring MVC 中使用 @...
  • javaee应用的分层结构 --javaee应用的分层结构:客户层,web层,业务层,企业信息系统层 分层模式的特点:伸缩性,可维护性,可扩展性,可重用性,可管理性 --事务:指一系列的数据库操作,这些操作要么全做要么全不...
  • 由于某些原因,需要在2个不同的树视图中显示来自mysql数据库的数据.例树视图1(使用列表标记):level1 (Root)level2level2level3level3level4level4level2level3level3level4level4树视图2: 我目前正在研究这个PHP...
  • 数据库调优分层思想

    2014-12-27 23:08:00
    数据库调优分层思想 1.调优策略 1)*号的处理(只提取必要字段,减少流量) 最好是用,有用的字段,减少流量。 表结构会改变,增加或者减少某列,如果*号全部查询出来 会造成代码逻辑错误。 2)大SQL(拆分,...
  • oracle作为庞大的体系,如何理解它的结构,就要分层来看。 所谓物理结构,就是存储在操作系统中的文件,包含控制文件、数据文件、重做日志文件、其他(初始化参数文件,跟中文件,警告文件,备份文件,口令文件)。...
  • <p>I'm asking for your help, because I'm not an advanced mysql user, and I'm not very conscious about every operation that I'm able to do. <p>The project that I'm working onto is a web-app ...
  • 数据库数据结构模型习题 分层数据模型 (Hierarchical Data Model) This model is like a hierarchical tree that means tree structure is used to construct a hierarchy of records in form of node and branches;...
  • 本章主要介绍数据模型和数据库系统的结构,主要包括概念模型、逻辑模型和物理模型以及数据库系统的三级模式。概念模型是对现实世界的抽象和模拟,逻辑模型是为了方 便计算机处理数据所采用的模型,物理模型是数据在...
  • [数据库]数据库存储层级结构数据

    千次阅读 2014-06-03 21:21:02
    无论你想建立自己的论坛,在你的网站上从一个邮件列表发布消息,或编写自己的cms:你将会遇到一种情况:将分层数据(层级结构)存储在数据库中。除非你使用一个类似xml的数据库,通用的关系型数据库是很难做到这一点。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,825
精华内容 730
关键字:

数据库分层结构