This is part 2 of my original post, which focused on extracting object names from the DDL of database views using Aster's NER function. In this post I'll talk about how to visualize the sub-dependencies of a view that references multiple other views. The ultimate goal of this exercise is to be able to identify, for each view, the base tables that store the data being retrieved.
At the end of the last post we were left with a table (objectlinks) that had 4 columns. Objectlinks holds one row for each object that is referenced in a given view's DDL. Let's take a look at another DBC view, DBC.ChildrenX:
select * from objectlinks where objectfullname = 'DBC.CHILDRENX'
Here we see that DBC.ChildrenX is a view and its DDL contains references to 7 other objects, 5 of which are tables and 2 are other views. We know that some of the data contained within DBC.ChildrenX comes from those 5 physical tables, but what other references exist within the two other views that are dependents of ChildenX? In order to do this, we need to self-join the table objectlinks every time that we see a dependency of type "V". We also need to do this dynamically since there is no limit to the number of nested views that can exist as dependencies of other views. This type of dynamic recursive logic is very difficult to implement with standard SQL.
Luckily, we have a SQL-GR function in our Aster toolkit called gTree. gTree, which runs on the Aster graph engine and is used for hierarchical analysis, can be used to build and traverse tree structures. Let's take a look at the syntax:
create table viewpaths
distribute by hash(path)
FROM gTree (
ON (select distinct dict as objectfullname from tblvw_dict) AS vertices PARTITION BY objectfullname
ON (select objectfullname as objectfullname,entity as entity from objectlinks
where objectfullname <> entity) AS edges PARTITION BY objectfullname
ON (select dict as objectfullname from tblvw_dict where objecttype = 'V') AS root PARTITION BY objectfullname
'Propagate (objectfullname) AS start_vertex',
'Current (objectfullname) AS end_vertex',
where "leaf()" = 'true'
order by start_vertex);
We need to provide gTree with three inputs - the edges, the vertices, and the roots of our tree. The roots of our tree are the individual views that we want to see the dependencies for. We want to tree to start propagating from the view and then branch/leaf out to show the dependencies underneath that view. The vertices are the different objects that can possibly exist in the tree - in our case, this is just a list of all the tables and views that could possibly appear as dependencies of the views. Finally, the edges are rows that indicate the relationships between all of the vertices and the roots - this is just think information from our objectlinks table.
As I'm sure you've noticed, there are a couple of other arguments that we need to pass the gTree function:
Let's take a look a the gTree output from our function call above. Since we're looking at the view DBC.ChildrenX, we want to see all rows that started with the DBC.ChildrenX root:
SELECT * FROM viewpaths WHERE start_vertex = 'DBC.CHILDRENX'
These result rows represent all of the branches of a tree with DBC.ChildrenX as the root vertex. With this output, we can easily use Aster's Visualizer function to show the view dependencies as a sankey chart like below. I'll demonstrate how to build an App Center app for quick view dependency visualization in a later blog post.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.