精华内容
下载资源
问答
  • 领域模型设计
    千次阅读 多人点赞
    2020-07-27 14:48:11

    领域模型设计

    一、前言

    现代微服务系统一般涉及的业务流程多,系统交互场景丰富,为了合理切分业务领域,恰当定义业务边界,并以此开发出“高内聚,低耦合”的代码,采用DDD(Domain-Driven Design)领域驱动设计思想就能很好地实现这个目标,根据业务领域合理分层软件架构,让系统拓展性更强,结构更清晰,更灵活,复用程度更高,轻松应对各种复杂的业务需求。

    二、领域与对象

    1.什么是对象
    对象在面向对象定义之中,也规定了一些基本的特征:
    (1)封装:保护内部的操作不被破坏;
    (2)继承:在原本的基础之上继续进行扩充;
    (3)多态:在一个指定的范围之内进行概念的转换。
    2.什么是领域驱动设计
    领域驱动设计(Domain-Driven Design 简称DDD),是一套综合软件系统分析和设计的面对对象建模方法,采用领域模型概念,统一分析和设计编程,使软件能够更加灵活快速地跟随需求变化。
    领域驱动设计的核心在领域模型,领域模型的核心在业务知识。
    3.什么是领域对象
    领域对象(Domain Object)分为实体对象(也称聚合根)和值对象。
    实体对象是具有生命周期、有唯一标识、可以通过唯一标识判断相等性、有增改删查操作、可记录状态的对象。
    值对象是指起描述作用,无唯一标识、只能通过属性判断是否相等、即时创建、用完就回收的不可变对象。值对象必须通过实体对象进行操作。
    4.领域模型中的实体类关系
    领域模型的实体类分为视图对象VO(View Object)、数据传输对象DTO(Data Transfer Object)、领域对象DO(Domain Object)、持久化对象PO(Persistent Object)四种类型,各种实体用于不同业务层次之间的交互,并在各层次间实现转化,如下图所示:
    在这里插入图片描述

    5.对象和领域的关系
    领域是更大的对象,是可以直接产生业务价值的模型,只包含多对象的行为整合,不包含对象的属性,从而实现领域的行为共享。
    领域模型是对业务需求的一种抽象,表达了领域概念、领域规则以及领域概念之间的关系。一个好的领域模型是对统一语言的可视化表示,通过它可以减少需求沟通可能出现的歧义;通过提炼领域知识,并运用抽象的领域模型去表达,就可以达到对领域逻辑的化繁为简。模型是封装,实现了对业务细节的隐藏;模型是抽象,提取了领域知识的共同特征,保留了面对变化时能够良好拓展的可能性。
    领域模型以可视化的方式清晰地表达了业务含义,我们可以根据这个模型来指导后面的程序设计与编码实现。当增加新的需求或者需求发生变化时,我们能够敏锐地捕捉到现有模型的不匹配之处,并对其进行更新。领域模型传递了知识,可以作为交流的载体,符合人们的心智模型,有利于让开发人员从纷繁复杂的业务中解脱出来。

    在这里插入图片描述

    三、复杂领域设计原则

    1.拆分子域建立领域模型
    根据业务特点考虑流程节点或功能模块边界因素,按领域逐级分解成大小合适的子域,针对子域进行事件风暴,记录领域对象,初步确定各级子域的领域模型。
    2.领域模型微调
    梳理领域内所有子域的领域模型,对各子域模型进行微调,这个过程重点考虑不同聚合对象的重新组合,同步需要考虑子域里对象的聚合边界、服务以及事件之间的依赖关系,确定最终的领域模型。
    3.微服务设计和拆解
    根据领域模型的边界和微服务的拆分原则,完成微服务的拆分和设计。

    四、领域驱动设计和实施

    1.步骤一、事件风暴
    (1)场景分析
    根据不同角色和场景,全面梳理从前端操作到后端业务逻辑之间发生的所有操作、命令、领域事件以及外部依赖信息。
    (2)领域建模
    领域建模是一个收敛的过程。过程分为三步:第一步根据场景分析中的操作集合定义领域实体;第二步根据领域实体业务关联性定义聚合;第三步根据业务和语义边界等因素,定义领域模型。
    (3)微服务设计和拆分
    综合考虑职责单一性、性能、版本发布频率、团队沟通效率、技术异构等因素,合理设计和拆分微服务。
    2.步骤二、领域对象服务矩阵
    将事件风暴产生的领域对象按照各自所在的微服务进行分类,定义每个领域对象在微服务中的层、领域类型和依赖的领域对象,主要是为了确定实体、方法、服务等领域对象在架构中的位置以及对象之间的依赖关系,形成服务矩阵,细化了领域对象之间的关系,补充了事件风暴过程中可能遗漏的细节。
    3.步骤三、领域模型服务架构
    根据领域模型中领域对象的属性和服务矩阵,设计符合领域模型的技术架构,架构要能清晰地体现微服务实体间的联系,各层级之间的关系,以及服务组合和编排的关系。
    4.步骤四、代码模型设计
    根据DDD技术架构设计,搭建微服务架构体系,定义各层的微服务工程,各层的领域对象所在的包、类、方法、接口,领域中一个聚合对应一个聚合包。

    五、领域划分

    领域是自上而下的划分,不仅需要在这些相关联的领域有着极其丰富的经验,脑海中有着清晰且成熟的领域模型图。
    而自下而上,也就是本文所讲的,主要思想是从需求出发,划分出实体后,对实体进行归类,最终提炼出领域。
    1)对需求进行充分分析,提炼通用语言,从通用语言中抽象出实体
    我们首先对需求进行充分分析,提炼通用语言,从通用语言中抽象出实体。
    2)按照职责相似度,对实体进行归类,抽象出领域
    通过上面的步骤,我们得到了很多实体,然后按照职责的相似度对实体进行归类,相似度高的为一类,每一类给他们起一个名字,这就是领域。

    六、逻辑架构设计

    在这里插入图片描述
    逻辑架构图主要分为业务层、领域层、数据持久层,其他微服务模块通过zuul网关区分不同业务标识对应的服务路由到业务层,然后业务层通过组合、编排领域层服务,实现业务流程,领域服务操作领域对象(聚合根)和值对象,实现领域对象的属性修改和一系列领域对象行为,调用基础设施层完成完成一系列基础服务和数据库原子操作,实现数据持久化。

    七、DDD软件分层设计

    1.分层概述
    (1)业务层system-xxx-application:组合与编排各领域服务,实现业务流程。
    (2)springcloud微服务接口jar包system-xxx-feignclient:暴露微服务领域接口。
    (3)领域层system-xxx-domain:单领域服务实现。
    (4)领域接口jar包 system-xxx-domain-api:定义领域对象和操作接口。
    (5)基础设施层system-xxx-infrastructure:数据存储与处理。
    (6)公共服务 system-domain-common-xxx:公共配置、工具类。
    (7)system-domain-data-config:Spring容器扫描配置
    2.分层结构图
    总体上分为业务层、领域层、基础设施层,前端通过restful方式请求业务层,业务层通过Spring Cloud的FeignClient接口实现远程调用领域层的微服务,领域层通过自定义Spring容器扫描配置注入不同数据源的组件,从而实现多数据源的操作。
    在这里插入图片描述

    3.层级maven依赖关系
    在这里插入图片描述

    更多相关内容
  • DDD领域模型设计

    千次阅读 2021-03-08 11:33:09
    一、DDD领域模型设计概念 DDD的全称为Domain-driven Design,即领域驱动设计; 分层架构:UI层、应用层、领域层、基础设施层; User Interface 负责向用户展现信息,并且会解析用户行为,即常说的展现层。 ...

    一、DDD领域模型设计概念

    DDD的全称为Domain-driven Design,即领域驱动设计;
    分层架构:UI层、应用层、领域层、基础设施层;
    User Interface
    负责向用户展现信息,并且会解析用户行为,即常说的展现层。
    Application Layer
    应用层没有任何的业务逻辑代码,它很简单,它主要为程序提供任务处理。
    Domain Layer
    这一层包含有关领域的信息,是业务的核心,领域模型的状态都直接或间接(持久化至数据库)存储在这一层。
    Infrastructure Layer
    为其他层提供底层依赖操作。
    层结构的划分是很有必要的,只有清晰的结构,那么最终的领域设计才宜用,比如用户要预定航班,向Application Layer的service发起请求,而后Domain Layler从Infrastructure Layer获取领域对象,校验通过后会更新用户状态,最后再次通过Infratructure Layer持久化到数据库中。
    在这里插入图片描述
    1、Java动物对象实例

    public class Dog {
        private int age;
        private String color;
        public int getAge() {
            return age;
        } //吃
        public void eat(Object food) {
            System.out.println("吃...");
        } //睡
        public void rest() {
            System.out.println("睡...");
        }
    }
    

    2、贫血模型的例子

    public class Dog {
        private int age;
        private String color;
        private String status;
        public int getAge() {
            return age;
        }
        public void setAge(int age) {
            this.age = age;
        }
        public String getColor() {
            return color;
        }
        public void setColor(String color) {
            this.color = color;
        }
        public String getStatus() {
            return status;
        }
        public void setStatus(String status) {
            this.status = status;
        }
    public class DogService {
        //吃
        public void eat(Dog dog, Object food) {
            dog.setStatus("吃");
            System.out.println(dog.toString() + food.toString());
        }
        //睡
        public void rest(Dog dog) {
            dog.setStatus("睡觉");
            System.out.println(dog.toString() + " 睡觉觉...");
        }
        public Dog getDog(){
            return new Dog();
        }
    }
    public class DogController {
        public void eat() {
            Object food = new Object();
            DogService ds = new DogService();
            Dog dog = ds.getDog();
            ds.eat(dog, food);
        }
        public void rest() {
            DogService ds = new DogService();
            Dog dog = ds.getDog();
            ds.rest(dog);
        }
    }
    

    Dog类只有针对属性的get,set操作,行为被搬到service类了.这种风格是贫血模型的代表。
    缺点:根据个人代码风格,有的controller类很重,有的service类很重。
    最重要的是如果不具备一定的领域分析的知识,往往建出来的类似Dog的领域类是错误的,甚至会根据经验先建数据库再建领域类。

    二、Domain层实现

    Domain层是具体的业务领域层,是发生业务变化最为频繁的地方,是业务系统最核心的一层,这一层包含了如下一些domain object:entity、value object、domain event、domain service、factory、repository等。
    1.实体类:( Entity)
    领域实体是domain的核心成员,domain entity具有以下三个特征:
    唯一业务标识
    持有自己的业务属性和业务行为
    属性可变,有着自己的生命周期,故实体对象可能和它之前的状态不一样,但有同样的唯一标识,是同一个实体。
    例:狗
    2.值对象( ValueObject)
    内部值是不变的,不存在生命周期;
    例:color、point、money、address
    对象是根据值来确定的,可以在不同实体中使用,值对象通常不可变的
    3.Service
    无状态对象
    当一个属性或行为放在实体、值对象中模棱两可或不合适的时候就需要以Service的形式来呈现;
    例:转账、领域逻辑是动词
    三种模型的复杂度是不一样的,在领域建模选Model模棱两可时,优先选择简单模型原则。模型复杂度顺序 Service > Entity > ValueObject

    三、聚合

    1.聚合-对象的依赖关系;
    2.设计聚合时要考虑一致性.意味着一个客户请求只在一个聚合实例上执行一个命令方法;
    3.聚合设计原则:设计小聚合。大的聚合即便能保证事务的一致性,也依然可能限制系统的性能可伸缩性;
    4.通过唯一标识引用其它聚合。
    聚合之间有依赖关系时不要直接写依赖对象,通过唯一标识来引用。通过标识引用可以将不同限界上下文的分布式领域模型关联起来。
    5,在边界之外使用最终一致性。当一个聚合执行命令方法时,还需要在其它聚合上执行任务,使用最终一致性。一种实用的方法可以支持最终一致性,即一个聚合的命令方法发布的领域事件及时地发布给异步的订阅方。
    6.不要在聚合中注入资源库和领域服务。

    四、领域事件

    1.啥是领域事件?
    领域专家所关心的发生在领域中的一些事件。
    将领域中所发生的活动建模成一系列的离散事件。每个事件都用领域对象来表示…领域事件是领域模型的组成部分,表示领域中所发生的事情;
    首先是解决领域的聚合性问题。DDD中的聚合有一个原则是,在单个事务中,只允许对一个聚合对象进行修改,由此产生的其他改变必须在单独的事务中完成。如果一个业务跨多个聚合对象,领域事件会是一个不错的工具来解决这个问题。通过领域事件的方式可以达到各个组件之间的数据一致性,通过最终一致性取代事务一致性。
    其次领域事件也是一种领域分析的工具,有时从领域专家的话中,我们看不出领域事件的迹象,但是业务需求依然有可能需要领域事件。动态流的事件模型加上结合DDD的聚合实体状态和BC,可以有效进行领域建模。
    2.领域事件的技术实现
    领域事件的技术实现实质上观察者模式的实现。技术的实现都好讲,关键是理解观察者模式在领域建模中的应用场景。
    3.领域事件需要关注的类容。
    一,消息设施最终一致性。
    二,事件存储:
    1),将事件存储作为一个消息队列使用。
    2),检查由模型命令方法的所产生的所有结果的记录
    3),使用事件存储中的数据进行业务预测和分析。、
    4),通过事件存储重一个聚合。
    5),撤销对聚合的操作
    4,转发存储的架构风格。

    五、领域服务

    1、领域服务表示一个无状态的操作,强调一个无状态的操作,状态应该在实体中维护,领域服务处理是无状态的逻辑过程;
    2、实现某个领域的任务,即做的也是领域内的事情,是通用语言的表达。而不是应用服务,应用服务是领域服务的客户方,比如api聚合服务,不应该做领域内的事情。也不是基础设施服务,比如DB或消息基础组件。特别是不能跟现在常用的mvc+s架构中的s(service)层混淆,这种情形下的s,很多时候是持久层接口组装,更像是DDD中的资源库的概念。
    3、先考虑聚合或值对像的建模,不适合,然后才使用领域服务。聚合(实体)和值对像才是最重要的DDD建模对象,如果反而首先使用领域服务,容易导致“贫血领域模型”。既然不适合直接在实体或值对像上建模,也基本说明很多时候涉及到多个实体或值对像。
    那什么时候该使用领域服务呢?
    1.执行一个显著的业务操作过程
    2.对领域对象进行转换
    3.以多个领域对象作为输入进行计算,结果产生一个值对像基本就是跟上面对领域服务概念的理解是一致的。
    领域服务实现是否需要独立接口?
    优点:使用接口表达领域概念,而技术实现可以比较随意,比如放在基础实施层,或者在依赖倒置原则中,放在应用层实现也可以;独立接口有利于解耦,通过依赖注入或工厂可以完全解耦客户端与具体实现
    缺点:得写两个对象代码,特别对于java,还得分两个文件,阅读代码也增加点难度,而很多时候一个接口也只有一个实现;另外一个命名问题,在DDD中领域对象名称(对应语言实现的类)和操作名称(对应函数名)是很重要的,是需要表达通用语言的概念的。但如果定义独立接口,也就是会XXXservice的名字来定义接口,但服务实现用什么命名呢?如果用XXXserviceImpl,那其实也说明可以不需要定义独立接口了。测试领域服务其实测试方面,我觉得没有很多需要关注的,或者说我比较少测试方面的需要。但在测试领域服务一节有句话却比较有意思“我们希望对领域服务进行测试,并且希望从客户端的角度对领域服务进行建模,同时我们希望测试能够反映查领域服务的使用方式”,即通过测试代码,告诉客户端怎么使用领域服务。这其实是测试代码的一个重要的作用,但也经常被我们忽略的。
    注意:领域服务不能过多,那变成贫血模型了。

    六、应用服务层

    应用层通过应用服务接口来暴露系统的全部功能。在应用服务的实现中,它负责编排和转发,它将要实现的功能委托给一个或多个领域对象来实现,它本身只负责处理业务用例的执行顺序以及结果的拼装。通过这样一种方式,它隐藏了领域层的复杂性及其内部实现机制。
    应用层相对来说是较“薄”的一层,除了定义应用服务之外,在该层我们可以进行安全认证,权限校验,持久化事务控制,或者向其他系统发生基于事件的消息通知,另外还可以用于创建邮件以发送给客户等。

    七、构架及架构风格

    一, 架构部分:

    1. 限界上下文、子域:
      领域:通常是指整个系统的业务边界.也可以指子域如核心域等。
      子域:业务系统的某个方面。
      限界上下文:同样的是业务系统中某个方面,它比子域的粒度更小。通常一个子域可以只包含一个限界上下文。
      光看这个,有点绕。但直白点理解,其实它们就是架构中的关于系统/模块的划分。系统可以划分为多个子系统,子系统当然还可以划分为更小的子系统。或者业务模块的划分。
      如果还不够直白,那么如果有微服务经验,可以想想、对照服务的划分。
      2)上下文映射图:
      在这里插入图片描述
      DDD中的图示。个人理解:其实它就是各子系统/模块的依赖关系。比如现在典型电商系统子系统划分 会员系统、商品管理系统、资金系统。。。
      在这里插入图片描述
      商品、资金均依赖于会员系统。基本上资金限界上下文同时也是一个子域。同时它们也各自被划分为了一个微服务系统。

    二,架构风格:
    《实现领域驱动设计》关于架构一章,章节名虽然叫架构,但应该理解成架构风格。就象传统的三层架一样,是一种架构风格。
    1)六边形架构
    在这里插入图片描述
    它并不是真的有六条边.它也叫端口+适配器.端口可以理解成http,socket自定义传输协议、或者某个RPC调用协议等。六边形的内部代表了application和domain层。外部代表应用的驱动逻辑、基础设施或其他应用。内部通过端口和外部系统通信,端口代表了一种协议,以API呈现。
    一个例子:
    在这里插入图片描述
    2) Rest
    RESTful风格的架构将‘资源’放在第一位,每个‘资源’都有一个URI与之对应,可以将‘资源’看着是ddd中的实体;RESTful采用具有自描述功能的消息实现无状态通信,提高系统的可用性;至于‘资源’的哪些属性可以公开出去,针对‘资源’的操作,RESTful使用HTTP协议的已有方法来实现:GET、PUT、POST和DELETE。
    3) CQRS
    CQRS就是平常大家在讲的读写分离,通常读写分离的目的是为了提高查询性能,同时达到读/写的解耦。
    CQRS适用于极少数复杂的业务领域,如果不是很适合反而会增加复杂度;另一个适用场景为获取高性能的服务
    4)事件驱动架构
    事件可能有不同类型,这里主要只关心领域事件。
    在这里插入图片描述
    象不象微服务架构中引入消息中间件来解耦和最终事务一致?
    5)管道和过滤器风格.
    管道过滤器来源于linux命令类似 ps -ef | grep tomcat . | 即管道。ps 处理的结果经过管道符| 作为下一个命令的输入。
    《实现领域驱动设计》中举了个基于事件的发布、订阅的例子来实现管道和过滤器架构风格。事件的发布订阅中心作为管道。事件的发布、订阅方作为过滤器。
    推而广之,考虑基于消息中间件的管道过滤器。

    八、实现

    采用三层结构的架构风格就没有领域相关的类容了吗?
    答案当然是有的,但是不象DDD这样有明确的区分。往往因为程序员没有相关概念或多多思考就容易引发问题。

    public class SearchController {
    private SearchService service;
    @RequestMapping(value="search")
    public List search(String searchStr) {
        service.search(searchStr);
    }
    }
    public class SearchService{
      public List search(String  str){
       if(系统变量=="solor"){
          solorService.search(str)
      }else {
        dbService.search(str);
    }
    }
    }
    

    功能很强大,支持数据检索和solor检索。但是再看,solor检索和数据检索明显不是一个玩意,不应该同时出现在SearchService里。从DDD观点来看,也明显属于不同的领域实现模型。即使在同一个子域里,划分微服务那它也应该是两个微服务实现。显明扩展性不好。
    3.作为六边型架构风格的实现,看看一个开发包的结构图在这里插入图片描述

    展开全文
  • 数据仓库之模型设计

    千次阅读 多人点赞 2020-03-22 21:01:22
    数据仓库(模型设计) 一、数据仓库与数据库的区别 1、数据仓库是集成的,数据库为单一的业务提供服务。 2、BI结构:数据整合层、数据服务层、应用分析层、信息展现层 3、数据层库结构 ODS(临时存储层),一般...

                            数据仓库(模型设计)

    一、数据仓库与数据库的区别

    1、数据仓库是集成的,数据库为单一的业务提供服务。

    2、BI结构:数据整合层、数据服务层、应用分析层、信息展现层

    3、数据层库结构

            ODS(临时存储层),一般都是贴源设计、业务数据库是什么,ODS层就是什么

    PDW/DW(数据仓库层),将年月日,拆分成年、月、日字段,一般采用Int类型;通过ODS层到DW层的etl脚本对数据进行数据清洗、进行设计。分部门根据业务需求进行设计。如果没有业务需求,就根据源系统的表结构和自己建模经验去处理。

    DM(数据集市层),维度建模,星形模型,雪花模型。需要什么数据就去拉取什么数据。

    APP(应用层),报表展现,需要的数据,与DM层处于同一级别。

    4、ODS层分为增量更新或者全量更新;PDW层一致的、准确的、干净的数据,一般遵循数据库三范式设计。

     

    二、数据仓库的特点

    1、数据仓库是面向主题的,比如商品主题,订单主题。(领导关注那些方面)
    传统数据库面向应用,提供什么功能。数据仓库面向分析,提供那些主题的分析。
    从规模来讲依次是,数据仓库、数据集市、数据报表。
    2、数据仓库是集成的,数据源是分散的,来自不同的应用。数据仓库中的综合数据,不能从源数据中直接得到,一般会经过etl过程(数据抽取、数据转换、数据加载)。数据抽取一般会定时的进行抽取,避免对业务系统造成影响,一般叫做T-1抽取、T+1抽取。目前企业对数据的实时性要求越来越高,比如实时监控一个实时的活动效果,并根据效果进行不同策略的营销手段,保持活动的效果。
    3、数据仓库是不更新的,数据仓库反应的是一段相当长的时间内的数据内容,主要的操作集中在数据查询上。 一般数据结果计算出来之后,特别是明细数据,会存放在关系数据库中,因为主流的报表工具都支持数据库。
    对数据库的查询,最基本的操作是创建索引,比如300万的数据根据手机号查询需要十几秒,创建btree索引之后,需要几十毫秒。
    4、数据仓库中的数据是随着时间而变化的。

    三、数据仓库的模型设计

    A. 数据建模方法论

    数据仓库模型设计遵循“自顶向下、逐步求精”的设计原则。

    模型设计分为三个阶段(四):

    1,业务模型

        主要是从业务需求角度去分析问题

    2,概念模型

    对业务的范围和使用,从高度上进行抽象概括,也就是划分主题域。

    一般划分为8个主题域:

    客户、服务、服务使用、账务、结算、资源、客服、营销

    为什么要划分主题域?

    划分主题域,是根据业务的应用和需要来划分的,是用来达到数据与业务紧耦合的目的。

    3,逻辑模型

    对概念模型中的主题进行细化,定义实体与实体之间的关系,和实体的属性。

    即定义具体表的作用,表与表的约束,表的字段。形成ER图。

    这些实体的设计都是基于业务规则,可以说,这一阶段主要面对的是业务。也就是“业务驱动建模

    4,物理模型

    依照逻辑模型,在数据库中进行建表、索引等。数据仓库,为了满足高性能的需求,可以增加冗余、隐藏表之间的约束等反第三范式操作

    这一阶段,主要针对的是数据库、硬件、性能。

    范式

    第一范式:数据库表的字段都是单一属性,不可再分。

    第二范式:数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖。

    (部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况)。即要求所有属性都依赖于主键。

    第三范式:数据库表中不存在非关键字段对任一候选关键字段的传递函数依赖

    范式是向下兼容的。

    例如:

    学生ID

    学生名称

    学生部门

    课程ID

    课程名称

    成绩

    60100

    张三

    教育学院,心理系,1班

    English_1

    英语1

    80

    1)违反第一范式。因为:学生部门可以分解为:学院,系,班级

    2)违反第二范式。因为:关键字段是学生ID和课程ID, 但存在“课程ID”决定课程名称和课程学分。

    3)违反第三范式。因为:关键字段是学生ID,但存在可能名称和学分依赖“课程ID”。

    星型模型和雪花模型

    首先,他们都是由一个事实表和一组维度表组成。

    星型模型,也被称为维度建模

    区别在于:

    星型模型:维度表直接跟事实表连接,图型像星星。

    如区县和地市做为同一维度都在地市表中。

    *维度预处理,维度会预先进行分类,排序等预处理。

    雪花模型:一些维度表不是直接与事实表连接,而是通过维度表中转,图形像雪花。

    例如:

    图1:星型模型

    图2 雪花模型

    从性能来看,星型模型查询性能好。

    为了提高性能,可以允许违反第三范式,适当的冗余、隐藏表之间的约束。

    维度建模

    将商业维度融合到数据模型中,由此得名维度建模。

    或者说,为了分析方便(商业应用要求),将同一维度的不同层次的维度(如地市ID,区县ID)都融合到事实表中(如用户宽表)。

    维度模型也是星型模型。

    它 强调的是先对维度进行预处理,将多个维度集合到一个事实表,形成一个宽表,如上面的用户统一视图。包含了20多个维度。这样可以组合各维度,形成灵活的报表查询。

    B. 分层设计原则

    电信行业的数据仓库都采用了分层设计原则。

    总的来说,分三层:接口层、中间汇总层和应用层。

    应用层

    数据集市

    地市数据集市、数据挖掘

    应用层

    KPI报表、cagnos、主题分析、指标库

    中间层

    深度汇总层

    信息聚合:用户统一视图、3G用户统一视图、固话用户统一视图

    业务拓展:用户行为、增值业务、集团业务、国际业务

    轻度汇总层

    清单汇总、用户属性聚合、费用汇总、集团客户汇总等

    接口层

    存储层

    接口备份、增量转全量、减少I/O(分常用数据和历史数据)

    接口层

    日接口、月接口、增量接口、全量接口

    特别强调的是:

    中间层是数据仓库最重要的一层。直接决定了数据仓库的性能。

    一般的做法是:

    1)数据汇总。将底层数据按维度进行小颗粒度汇总

    2)信息聚合。将多张表的信息聚合在一个表中。这样的好处,是避免使用表关联,提高查询性能。

    C. 主题域设计方法

    如果说分层设计,是横向的设计原则,那么主题分域是纵向的处理方法。

    具体做法就是从业务上,高度的抽象和归纳,将数据划分为不同的主题域。

    分域后的好处:业务紧耦合、便于数据拓展、便于使用。

    域是要具有明显的表命名规则,如:

    用户信息域—— user

    通信行为—— call

    数据业务—— gprs

    账务 —— bill

    客户服务—— serv

    xx经分 系统的数据架构图:

             

    展开全文
  • Django教程 —— 模型设计

    千次阅读 2020-10-19 20:00:39
    模型设计 我们一般操作数据库的时候都是通过写sql语句,那么能不能不写sql语句就可以操作数据库呢? 可以利用ORM框架。 ORM框架 O是object,也就 类对象 的意思,R是relation,翻译成中文是关系,也就是关系数据库中...

    模型设计

    我们一般操作数据库的时候都是通过写sql语句,那么能不能不写sql语句就可以操作数据库呢? 可以利用ORM框架。


    ORM框架

    O是object,也就 类对象 的意思,R是relation,翻译成中文是关系,也就是关系数据库中 数据表 的意思,M是mapping,是映射的意思。在ORM框架中,它帮我们把类和数据表进行了一个映射,可以让我们通过类和类对象就能操作它所对应的表格中的数据。ORM框架还有一个功能,它可以根据我们设计的类自动帮我们生成数据库中的表格,省去了我们自己建表的过程。

    Django中内嵌了ORM框架,不需要直接面向数据库编程,而是定义模型类,通过模型类和对象完成数据表的增删改查操作。


    使用Django进行数据库开发的步骤如下:

    • 在models.py中定义模型类
    • 迁移
    • 通过类和对象完成数据增删改查操作

    Django模型设计

    在上篇文章中我们创建了一个图书管理系统(BMSTest),并部署了一个book应用。我们接着这个项目来介绍Django进行数据库开发过程,模型设计。


    1、定义模型类

    模型类定义在models.py文件中,继承自models.Model类。

    说明:不需要定义主键列,在生成时会自动添加,并且值为自动增长。


    设计图书类

    BookInfo
    类属性数据类型备注
    titleCharField(字符类型)图书名称
    authorCharField(字符类型)图书作者
    pub_dateDateField(日期类型)出版日期

    模型类的设计

    根据设计,在models.py中定义模型类如下:

    # -*- coding:utf-8 -*-
    """
    @Author   :Hui
    @Desc     :{模型设计模块}
    """
    
    from django.db import models
    
    
    class BookInfo(models.Model):
        """图书模型类"""
        title = models.CharField(verbose_name=u'图书名称', max_length=20)
    
        author = models.CharField(verbose_name=u'图书作者', max_length=20)
    
        pub_date = models.DateField(verbose_name=u'出版日期')
    

    参数介绍

    • verbose_name:详细备注名称
    • max_length:数据最大长度

    这里就简单的用了几个参数,详细参数的使用,大家可以查看Django官方文档。

    继承models.Model的类的设计都会对应一张数据库表。


    2、迁移

    迁移前目录结构如下图:

    Django 迁移文件夹

    迁移由两步完成:

    • 1.生成迁移文件:根据模型类生成创建表的迁移文件。
    • 2.执行迁移:根据第一步生成的迁移文件在数据库中创建表。

    生成迁移文件

    PyCharm Terminal 终端下输入如下命令:

    python manage.py makemigrations
    

    Django生成迁移文件


    执行生成迁移文件命令后,会在应用book目录下的migrations目录中生成迁移文件。

    生成迁移文件后的目录结构:

    Django迁移文件夹目录结构


    打开上图中的迁移文件,内容如下:

    # Generated by Django 3.1.2 on 2020-10-19 09:01
    
    from django.db import migrations, models
    
    
    class Migration(migrations.Migration):
    
        initial = True
    
        dependencies = [
        ]
    
        operations = [
            migrations.CreateModel(
                name='BookInfo',
                fields=[
                    ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                    ('title', models.CharField(max_length=20, verbose_name='图书名称')),
                    ('author', models.CharField(max_length=20, null=True, verbose_name='图书作者')),
                    ('pub_date', models.DateField(verbose_name='出版日期')),
                ],
            ),
        ]
    

    Django框架根据我们设计的模型类生成了迁移文件,在迁移文件中我们可以看到fields列表中每一个元素跟BookInfo类属性名以及属性的类型是一致的。同时我们发现多了一个id项,这一项是Django框架帮我们自动生成的,在创建表的时候id就会作为对应表的主键列,并且主键列自动增长。


    执行迁移文件

    PyCharm Terminal 终端下输入如下命令:

    python manage.py migrate
    

    执行结果

    (py_django) D:\Hui\Code\Python\DjangoProject\BMSTest>python manage.py migrate
    Operations to perform:
      Apply all migrations: admin, auth, book, contenttypes, sessions
    Running migrations:
      Applying contenttypes.0001_initial... OK
      Applying auth.0001_initial... OK
      Applying admin.0001_initial... OK
      Applying admin.0002_logentry_remove_auto_add... OK
      Applying admin.0003_logentry_add_action_flag_choices... OK
      Applying contenttypes.0002_remove_content_type_name... OK
      Applying auth.0002_alter_permission_name_max_length... OK
      Applying auth.0003_alter_user_email_max_length... OK
      Applying auth.0004_alter_user_username_opts... OK
      Applying auth.0005_alter_user_last_login_null... OK
      Applying auth.0006_require_contenttypes_0002... OK
      Applying auth.0007_alter_validators_add_error_messages... OK
      Applying auth.0008_alter_user_username_max_length... OK
      Applying auth.0009_alter_user_last_name_max_length... OK
      Applying auth.0010_alter_group_name_max_length... OK
      Applying auth.0011_update_proxy_permissions... OK
      Applying auth.0012_alter_user_first_name_max_length... OK
      Applying book.0001_initial... OK
      Applying sessions.0001_initial... OK
    

    Applying book.0001_initial... OK 说明我 book 应用下的 0001_initial 迁移文件迁移成功。

    迁移后的目录结构图:

    Django迁移后的目录结构


    Django默认采用 sqlite3 数据库,上图中的 db.sqlite3 就是Django框架帮我们自动生成的数据库文件。 sqlite3 是一个小型的数据库,通常用在手机中,它跟 mysql 一样,我们也可以通过sql语句来操作它。

    迁移成功后 sqlite3 数据库会创建 book_bookinfo

    • book 是应用的名称
    • bookinfo 是模型类的名称

    因此数据表的默认名称为:<app_name>_<model_name> ,应用名 + 下划线 + 模型名


    Django操作数据库表

    数据库表建好了,看看Django如何便捷的操作。

    打开 Pycharm Terminal 终端输入如下命令:

    python manage.py shell
    

    进入 项目的 shell 终端,进行简单的API操作。输入quit() 退出项目终端。

    Django项目终端


    查询

    首先引入book/models中的类:

    from book.models import BookInfo
    

    查询所有图书信息:

    BookInfo.objects.all()
    

    因为当前并没有数据,所以返回空列表

    >>> from book.models import BookInfo
    >>> BookInfo.objects.all()
    <QuerySet []>
    >>>
    

    添加

    添加图书信息

    from datetime import date
    from book.models import BookInfo
    
    
    book = BookInfo()
    book.title = '天龙八部'
    book.author = '金庸'
    book.pub_date = date(1967, 10, 7)
    
    # 保存并向数据库表添加图书信息
    book.save()
    

    然后在查看图书信息,是否添加成功

    >>> BookInfo.objects.all()
    <QuerySet [<BookInfo: BookInfo object (1)>]>
    

    all() 是查询所有,返回一个查询集,我们来是试试 get() 条件查询

    book = BookInfo.objects.get(id=1)
    

    返回的类型是 BookInfo 对象。可以利用这个对象来获取你想要的图书信。

    >>> book = BookInfo.objects.get(id=1)
    >>> book.title
    '天龙八部'
    >>> book.author
    '金庸'
    >>> book.pub_date
    datetime.date(1967, 10, 7)
    >>>
    
    

    这样是不是便捷多了,不用写 SQL 语句。

    修改更新

    >>> book.pub_date = date(1986, 6, 6)
    >>> book.save()
    >>> book.pub_date
    datetime.date(1986, 6, 6)
    
    

    删除

    >>> book.delete()
    (1, {'book.BookInfo': 1})
    
    # 在查询就为空了
    >>> BookInfo.objects.all()
    <QuerySet []>
    >>>
    
    

    公众号

    新建文件夹X

    大自然用数百亿年创造出我们现实世界,而程序员用几百年创造出一个完全不同的虚拟世界。我们用键盘敲出一砖一瓦,用大脑构建一切。人们把1000视为权威,我们反其道行之,捍卫1024的地位。我们不是键盘侠,我们只是平凡世界中不凡的缔造者 。

    展开全文
  • 关系数据库模型设计

    千次阅读 2020-05-19 17:13:17
    本文从现实世界-概念世界(信息世界)-机器世界(数据世界)逐级抽象,旨在以浅显易懂的语言描述关系数据库应该如何建模,最后用简单名了的描述给出关系模型设计范式的含义。
  • 数据仓库多维数据模型设计

    万次阅读 多人点赞 2017-11-09 18:14:59
    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。 数据仓库建模方法 大千世界,...
  • 数据仓库架构及模型设计基础

    千次阅读 多人点赞 2019-06-26 21:58:18
    Kimball的数据仓库包含高粒度的企业数据,使用多维模型设计,这也意味着数据仓库由星型模式的维度表和事实表构成。分析系统或报表工具可以直接访问多维数据仓库里的数据。在此架构中的数据集市也与Inmon中的不同。...
  • 第三章 概念模型设计(一)

    千次阅读 2020-04-16 23:01:55
    数据库设计是指对一个给定的应用环境,构造(设计)最优的数据模型,然后据此建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求。数据库设计的优劣将直接影响信息系统的质量和运行效果。设计...
  • Neo4j数据模型设计

    千次阅读 2017-06-19 09:30:17
    数据模型设计是数据建模的第一步,因为Neo4j不需要模式结构定义,所以使用简单框图就可以为一个项目或应用设计数据模型。创建数据模型之后,就可以使用SDN进行数据实体建模和一些数据访问的设计。 本文选自《Neo4j...
  • 数据仓库-物理模型设计

    千次阅读 2019-07-07 13:13:01
    在进行物理模型设计实现时,所考虑的因素有:I/O存取时间、空间利用率及维护的代价。 为确定数据仓库的物理模型设计人员必须做这样几方面工作:首先要全面了解所选用的数据库管理系统,特别是存储结构和存取方法...
  • 模型设计CWM规范

    热门讨论 2008-11-25 12:20:31
    CWM元模型设计的目的是最大化的重用对象模型Object Model (UML的子集) ,尽可能的共享通用的模型构建。最典型的是,CWM重用/依赖对象模型来描述面向对象的数据资源;另外,其它类型的数据资源的主要Metamodel元素,...
  • 数据仓库模型设计与工具

    千次阅读 2020-04-01 10:09:57
    数据模型对于数仓是最核心的东西,数据模型是数据组织和存储方法,模型的好坏,决定了数仓能支撑企业业务多久。 为什么大多数企业,数仓都要重建,这不仅仅是业务拓展、发展迅速,很大一部分是因为模型建的很烂。 ...
  • 业务建模和概念模型设计

    千次阅读 2018-11-28 09:36:56
    按照层次关系划分,数据路径上包括业务建模,概念模型设计,逻辑模型设计和物理模型设计。 业务建模是针对公司或者部门级的业务进行全方面的梳理和分解。 概念建模是对业务模型进行抽象出来实体以及实体与实体之.....
  • 数据仓库-逻辑模型设计(粗讲)

    千次阅读 2019-07-09 18:51:04
    逻辑建模能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用,它的作用在于可以通过实体和关系勾勒出企业的数据蓝图。 ...所以,我们必须对概念模型设计步骤中确定的几个基...
  • Navicat数据库模型设计总结:

    千次阅读 2019-06-28 17:06:41
    一,独立的属性必须分开。多对多关系可以合并在一张表上。(仅是初步的认识,后面待补充) 1,班级+老师+课程是两两多对多的形式,合在一起写,这个表会很...补:表格设计表名称不要占用关键字如group,order等
  • 数据仓库主题一(宽表模型设计

    万次阅读 2020-07-16 14:26:21
    一、典型的数据仓库建模思想一般主流分为两种 第一种 ER模型是数据仓库之父父 Bill lnmon 提出的建模方法是从全企业的高度设计 3NF 模型,用实体关系( Entity Relationship, ER )模型描述企业业 务,在范式理论上...
  • DDD 领域驱动模型设计 文章目录 《领域驱动设计》—— Thoughtworks洞见 《实现领域驱动设计》—— 沃恩·弗农 DDD-领域驱动设计 - 知乎 (zhihu.com) 一、架构的演变历程 ​ 学习DDD之前,先了解大致...
  • 设计E-R图之间关系 1.打开Navicat+Premium软件,开始设计表 2.设计表之间的关系 操作步骤: 选中关系图标,将某张表的一个字段拖动到另外一张表的字段。 设计表之间的关系: 4.导出成png 5.保存...
  • 第2章 ER模型设计 第1节 E-R模型的基本组成 E-R模型有什么作用 有助于数据库设计 是一种语义模型,模型的语义方面主要体现在模型力图去表达数据的意义 提供了在数据库设计过程中如何表示实体以及实体间联系的方法 ...
  • 购物商城之产品数据模型设计

    千次阅读 2017-07-10 11:03:05
    模型由产品、单品(SKU)、仓库三个主要部分组成,其中进货渠道(供应商)及销售渠道(代销商)部分只做简单展示,此次不做详细讲解,本方案设计初衷以适应实物线上线下进销存管理需求,所以对虚拟产品的销售暂未...
  • 一个在线ER模型设计的网站

    千次阅读 2019-08-08 21:47:07
    记录一个在线ER模型设计网站,可以导入MySQL,Oracle,SQLServer ,PostgreSQL 脚本生成ER模型,访问地址: https://www.freedgo.com/erd-index.html, 效果图如下:
  • 基于模型设计(MBD)——stm32篇

    千次阅读 2019-01-04 00:05:14
    如何在stm32芯片上实现MBD设计?? 目前开放的底层工具包有两种。 (1)waijung  (2)ST官网库 目前使用着两个库都一般,各有优势,都需要进一步完善。   案例 (1)LED灯项目 (2)串口通信项目 (3)...
  • 推荐几款软件界面模型设计工具

    万次阅读 2018-12-01 16:55:20
    界面模型设计中很实用的一个工具GUI Design Studio,可以让界面示意图实现基本的交互,便于演示、交流。 GUI Design Studio提供的了大部分C/S、B/S组件的示意图,可组合使用,在一般软件界面模型设计阶段基本可以...
  • 数据仓库的模型设计

    千次阅读 2017-04-05 00:12:25
    Technorati 标签: 数据仓库,模型设计 数据仓库的模型设计 A. 数据建模方法论 数据仓库模型设计遵循“自顶向下、逐步求精”的设计原则。 模型设计分为三个阶段: 1,概念模型 对业务的范围和使用,从...
  • 数据仓库星型模型设计与ETL

    千次阅读 2018-01-05 23:32:27
    根据样例数据库设计数据仓库 采用数据库——mysql 采用mysql提供的样例数据库——employees (http://dev.mysql.com/doc/index-other.html) 根据以下需求建立星型模型: 1.公司每个员工每月的薪资分别是多少...
  • 数仓模型设计详细讲解

    千次阅读 多人点赞 2021-01-03 00:01:59
    今天给大家分享下数仓中的模型设计,一个好的数仓项目首先看一下它的架构以及他所用到的模型,它们使用的模型也都是非常巧妙的,好了,我们话不说到直接开始。 一、维度建模基本概念     &...
  • 几款软件界面模型设计工具

    万次阅读 2017-05-04 10:38:23
    界面模型设计中很实用的一个工具GUI Design Studio,可以让界面示意图实现基本的交互,便于演示、交流。 GUI Design Studio提供的了大部分C/S、B/S组件的示意图,可组合使用,在一般软件界面模型设计阶段基本可以...
  • 数据库 - E-R模型设计

    万次阅读 2016-04-16 20:43:01
    数据库设计分为三个阶段: ...优化数据存储和访问物理设计(即对给定的基本数据模型设计一个适应环境的物理结构的过程,包括文件类型、索引结构和数据的存放次序等)。 E-R模型 即实体-联系模型,它提供不受任何DBM
  • 问题1:navicat的模型设计里面的标签有啥作用啊? 问题2:设计完表模型后如何把模型插入数据库里面啊? 问题3:模型设计能不能直接连数据库也一起自动生成啊? ![图片说明]...
  • 理论篇~第三章 数据模型设计

    千次阅读 2017-09-24 10:07:02
     数据仓库之父Bill Inmon提出的建模方法,是从全企业的高度设计一个3NF模型,用实体关系(Entity Relationship,ER)模型描述企业业务。其具有以下几个特点:  需要全面了解企业业务和数据 实施周期非常长 对建...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,294,219
精华内容 517,687
关键字:

模型设计

友情链接: Using FFT & Goertzel.zip