你是不是和我一样,在学习数据结构与算法时,了解了一下图这种数据结构之后,根本不知道它的用武之地在哪里?
在我查了资料之后,现在我可以跟你讲讲,图可以这么用!
概念介绍
先来了解一下什么是图.
图,是一种非线性表数据结构.
那么你可能会问了,什么是线性表结构哇,我怎么区别一种数据结构是线性的,还是非线性的呢.
哈哈,还好我机智,在这篇文章之前就写了一篇文章来介绍,如果还有疑问,楼上雅座请: [数据结构与算法]14 搞不懂线性结构,非线性结构?
在图中元素叫做顶点( vertex ),图中的一个顶点可以和其他任意顶点建立连接关系,这种建立的关系叫做边( edge )
无向图
上面给出的是无向图.看到这里你可能就觉得比较疑惑,这个无向图看起来没啥呀,怎么会有这种数据结构呢?
不知道你是怎么想的,我刚开始学的时候就有这种疑问,这是什么神仙数据结构哇,还会有应用场景?
既然有疑惑,那就给个应用场景:
假设,现在你和我是微信好友,那是不是应该你的好友列表里面有我,我的好友里面有你,这样咱们才是好友对不对~
那在数据库中如何表示呢?吼~这个时候无向图就登场了
你和我是微信好友,那就在咱俩之间来条线,表示咱俩之间有关系,一条线就解决了问题,真是完美至极啊
假设,(怎么又是假设,哈哈哈)上图中表示的就是 A,B,C,D,E,F 之间的关系,那你可能就发现问题了,有的顶点线比较多,比如 D 有四条线,有的就相对少一些,比如 B 有两条线.这些线就表示顶点的度( degree ).这个概念有啥用?
能一眼看出来谁的好友多!那这个功能有啥用?(好吧,这个功能好像是有点儿鸡肋,不过也算是一个应用场景
有向图
看到上面的无向图,基础不错的小伙伴肯定会说了,我还知道有向图呢!
呦呵,不错,有向图就是下面这个样子:
在无向图中,咱们知道一个顶点有多少条边,就说它的度为多少.
在有向图中呢,有指向顶点的,也有从顶点指出去的,基于无向图的概念,咱们把从这个顶点指出去的边称为出度,指向该顶点的边称为入度.
那么有向图会应用在哪些场景呢?微信好友这个场景是不太可以了
那么微博呢?
微博和微信有什么不一样呢?微信是你和我是好友,那么咱们的好友列表里一定是要有彼此的,拉黑或者删除彼此了,那就不能互相发送消息了.
但是微博呢?你关注了我,并不代表我就要关注你对吧?看到这里有没有一种豁然开朗的感觉~
那么我关注了多少人就是出度,多少人关注了我就是入度.
这样带入理解是不是会比较好一点儿?(我可真是个天才,哈哈哈
带权图
看完了无向图,有向图,相信就有人说,我还见过带权图!(陈独秀给我坐下!
带权图长啥样呢?就下面这个样子:
懵逼了,这每条边上的数字是个什么鬼呦
别急,咱们来个场景:大家都玩 QQ 嘛?(别跟我说不玩,配合一下嘛…
玩 QQ 的话,一定知道有 QQ 空间,然后空间里面有个「谁在意我」「我在意谁」的功能,就是下图:
那么有没有好奇过呢? QQ 怎么知道我在意谁,谁在意我呢?
就是通过带权图哇
你访问了一个人的空间,这条边的权重就增加一点儿;别人访问了你的空间,那这条边的权重就增加一点儿;这段时间你们两个人聊天聊得比较频繁,来个小火花,顺便在你们两者之间的边权重增加一点儿.然后根据这些边的权重从大到小排序就得出了「谁在意我」「我在意谁」
到这里,上面的一切理解都还 OK ?
那咱们继续.图是怎么表示的呢?
图这种数据结构,再怎么画顶点,画边,到最后在物理结构上是怎么存储的呢?
别急,你所疑惑的,我都帮你想到了
图的存储方法
图的存储方法主要有以下两种:
邻接矩阵的底层依赖一个二维数组.对于无向图来说,如果 i 与 j 之间有边,那就将 A[i][j] 和 A[j][i] 标记为 1 ;对于无向图来说,如果 i 指向 j ,那么 A[i][j] 值为 1 ,如果 j 指向 i ,那么 A[j][i] 值为 1 ;对于带权图来说, A[i][j] 存储的值就不是 1 了,而是对应的权重值.所以这是图最直观的一种存储方法.
啥,你跟我说这还不直观?该不会是没有看下图吧:
但是你发现问题了嘛,这样看起来确实是直观了很多,但是很浪费空间有没有!比如无向图,如果 A[i][j] 为 1 ,那么 A[j][i] 肯定也是 1 ,多存储 A[j][i] 根本没啥必要.就像买东西,明明一块钱能买到的东西,为啥非要花两块钱?
所以如果使用邻接矩阵来表示的话,一定要清楚它的缺点.
但这并不是说,使用邻接矩阵来存储就没啥优点.这天底下哪儿有那么绝对的事情呢.
首先,邻接矩阵的存储方式简单,直接,所以当我们需要获取两个顶点之间的关系时,相信我没有比这种存储结构更高效的了.
还有就是使用邻接矩阵存储图的另外一个优点就是方便计算,因为可以将很多图的运算转换成矩阵之间的运算.
先来看图:
乍一看,这不是散列表嘛!每个顶点对应一条链表,链表中存储的是与这个顶点相连接的其他顶点.
嘿嘿,直觉超棒!
如果你对散列表熟悉的话,应该知道,在散列表中,如果链太长了,会导致冲突概率增大,复杂度也蹭的一下升高.而且吧,链表的存储方式你也知道,不是连续的,所以相对于数组来说, CPU 读取就会慢一些,相对于邻接矩阵的存储方式,在邻接表中查询两个顶点之间的关系就没那么高效了.
所以在实际开发中要注意遇到这种情况该如何处理,或者在刚开始的时候就直接设计好实现方式.比如可以将邻接表中的链表改为平衡二叉树,或者红黑树.
我觉得对于数据结构来说,没有最好的,只有最合适的~
参考
- 极客时间—<数据结构与算法之美>
以上,就是想要分享的内容了
感谢您的阅读哇
转载：https://blog.csdn.net/zll_0405/article/details/105209800