汽车行业BI解决方案

2、 数据堆栈
        3. 2.1多维数据集结构 凭据**汽车俱乐部的数据源系统的特点，联合该BI系统的剖析需求，我们对多维数据集的设计接纳星型模式来表现和存储多维数据。以存储事实的怀抱值和各维度值的事实表为焦点，其中每一个事实表对应一个主题（如人事治理、财政治理主题等）；生存维属性的维度表（如主顾、时间维度等）围绕实事表，每一个维度表通过一个要害字直接与事实表关联。

       其中事实表是由若干外键指向维表组成多维联系以及若干怀抱变量，记载多维数据集各个维度的交点的怀抱值。而维度表则是主键以及若干属性形貌维的特征或维的条理。如上图财政主题的多维数据集中，日期、编报类型、科目、销售团队均为维度，而财政则为事实表。在财政表中，存在着日期、销售团队、科目、编报类型这几个维度的外键，而金额则已怀抱值的形式泛起；在各个维度表中，除标识维度信息的主键外，还包罗该维度的其它须要信息，如名称、类型等等。
4. 2.2怀抱值组
        在**汽车俱乐部BI系统中，存在着多主题域（如呼叫中央、GPS等）的多维数据集结构；以剖析需求出发，也存在着跨主题域的综合交织对比式剖析，这就需要接纳在统一个多维数据集中建设多个怀抱值组的方式来解决此类问题。其中每一个怀抱值组代表一个主题（如GPS、呼叫中央、财政剖析等），划分包罗与这个主题相关的维度和怀抱值（以财政剖析为例，维度包罗时间、科目等，怀抱值为金额），这样每个怀抱值组都说明晰一个主题并解决了响应的剖析需求。

       如上图中，以呼叫中央为主题域的多维数据集中，我们设计的怀抱值组分为基本信息、话务信息这两部门。其中基本信息主要围绕电话信息各项处置惩罚情形，如转站、回访、处置惩罚、跟踪等情形；话务信息则以人工座席的绩效剖析为主。 而对于这样的怀抱值组中，会泛起一些维度结构是在多个怀抱值组中使用到的（如呼叫中央案例中日期、时段维度等），这些维度可以称为共享维度。而对于某个维度只有特定的怀抱值组才使用到（如呼叫中央案例中，呼叫方式、线路类型维度等），则被称为私有维度。针对若干的维度结构和怀抱值组，我们可以通过维度用法来举行详细的设计。以怀抱值组的方式将多主题域的多维数据集举行处置惩罚，同时也将跨主题域的剖析提供了利便。
5. 2.3数据堆栈解决方案
       **汽车俱乐部是以实时为每一位客户提供迅速周密的救援服务为宗旨的汽车俱乐部。客户可通过多种方式申请为俱乐部会员，若是会员的爱车在行驶历程中发生故障，需要救援或拖车，可直接拨打俱乐部求救电话，俱乐部可通过内部呼叫中央、GPS等系统将即时、快速的到达事故现场，为会员排忧解难。
        针对俱乐部的现实营业逻辑，我们以救援历程中呼叫中央、GPS系统为焦点，剖析从会员请求救援最先，俱乐部内部处置惩罚请求救援历程中呼叫响应、受理时长、呼叫次数以及救援车辆到达、返回时长和救援旅程等。将救援历程中故障受理明细与俱乐部救援车辆派遣漫衍情形分为两大主题域，而两大主题域间以受理单号作为相互关联的依据，形成一套完整的呼叫、救援、处置惩罚、派遣的历程。
        故障受理明细主题，亦在通过日期、地域、客户、故障车、救援种类、员工、救援车、呼救订单维度，对故障受理历程中，救援俱乐部呼叫响应时长、客户呼叫救援次数举行剖析剖析。待相识故障情形后，会通过GPS系统将对救援车辆举行调遣。
        救援车辆派遣明细主题，围绕日期、地域、呼救订单、员工、救援车维度，将故障信息通过GPS系统定位救援车辆后，对救援车辆前往事故所在的在途时长、处置惩罚时长、返回时长及出车次数等举行剖析。
       在此多维数据集设计方案中，对于财政剖析（如救援车辆派遣用度等）来说，鉴于在现实营业中此处涉及救援服务类型、车型报价等诸多因素的影响，需对现实营业有更深层的相识，来对多维数据集设计方案举行增补。现在，在设计方案中，我们所使用的救援单号，是以事故发生时会员的首次呼叫时由于呼叫中央自动受理天生，而对于在一次事故中会员多次呼叫救援情形，则在呼叫次数上举行累计。

 2/3   首页 上一页 1 2 3 下一页 尾页