如果我们要存储诸如电视节目的数字资产，基础模型如下图所示。节目可以分为不同季度(Season)，具体细分为集数(Episode)，随后一集有不同的实例(对应同一集可能根据放映频道有不同的删减剪辑)，最后细分为视频片段。
案例来源：Scripps Networks(一家数字电视公司)
问题在于，以上的"基础模型"如果以关系型数据库来存放，需要建立很多表来表示不同的关系类型，而且数字资产也不只有视频这一种，最终会变成如下图所示的复杂情况。
在Scripps Networks的案例中，我们更关注于资产间的关系，比如一个厨房节目中对应的食谱有哪些，与这个节目相关的人物有哪些(如节目中出现的人和食谱作者)。
关系型数据库不擅长诸如此类的查询，而图数据库则擅长于表现数据资产的各种关联。
每个数字资产(Asset)都是一个抽象概念，可以视为一项知识产权(intellectual property)。不同资产间有着不同的关系，资产最后都会有一个实例(Instance)，表现为这个抽象概念对应的文件(文档/音乐/图片)，实例会连上对应的存储地址。
在一张图中可以存储不同类型的数字资产，如下图所示。绿色节点对应Asset，蓝色节点对应Instance，黄色节点对应Location。
子图1：下图所示的这张子图表示的是视频资源的子图。
对于电视节目的划分和第一张图相同，值得注意的是PART分为ABSTRACT_PART和CONCRETE_PART。
这样分的意义在于一集节目可以有不同的版本(同一集可能根据放映频道有不同的删减剪辑，以及清晰度的区分)，不同版本都会连接到与这一集对应的abstract_episode节点上，同时不同版本的节点都由VERSION关系互相连接。
子图2：表现了子图1的abstract_instance可以连接与这一集对应的一些文档资源。
子图3:一些其他的多媒体资源，如音乐资源。
这张图连接到了episode节点上，实际也可以连接到abstract_instance节点。
图数据库的灵活性是可以根据人们观看视频的习惯混剪视频(collection)，即包含了许多不同来源的视频片段。利用图数据库可以轻便地对混剪视频的关系进行表示。
