If we look at the check constraint, we can see a very basic definition.

That’s great and all but what if businesses decided it wanted to something more complex? What if Adventure Works decided that they won’t allow bike blades to more than five pounds? I actually don’t know if this is true. In fact, I’ve always wanted to be a little bit more handy with my bike. We run a quick SELECT * against the Production.Product database and we can see that the blade has a ProductID of 316.

At first blush, this may seem like an IF THEN statement would do just the trick. That, if we were to modify the CHECK constraint for product weight that we may wish to have something along the lines of, IF ProductID = 316 then Weight > 0.00 AND Weight <= 5.00.

When we look at the documentation for CHECK constraints, there doesn’t seem to be a way to incorporate IF THEN logic into a CHECK constraints. Perhaps then a user defined function or UDF might seem to be in order. A potential UDF CHECK constraint might look like the following:

We add the constraint to the table (I dropped the previous check constraint for pedagogical purposes):

If we perform a simple unrestricted update such as the following:

We get the following error message:

Msg 547, Level 16, State 0, Line 3

The UPDATE statement conflicted with the CHECK constraint “CK_PRODUCT_WEIGHT”. The conflict occurred in database “AdventureWorks2012″, table “Production.Product”.

The statement has been terminated. Let’s see what happens when we do something simple like perform an unrestricted update:

The outcome looks like this:

SQL Server parse and compile time:

CPU time = 2 ms, elapsed time = 2 ms.

SQL Server parse and compile time:

CPU time = 0 ms, elapsed time = 0 ms.

Table ‘Product’. Scan count 1, logical reads 1012, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:

CPU time = 15 ms, elapsed time = 110 ms.

(504 row(s) affected)

UDFs do not have a very good reputation. And using them in CHECK constraints can lead to performance issues and unexpected results as well.

Perhaps there is a better way. Think back to that freshman level Introduction to Logic course you took so long ago. There was a special identity for IF THEN statements. It was IF P THEN Q = NOT P OR Q. This simple logical equivalency can come in handy in a lot of places, especially where there isn’t support of IF THEN statements but there is for simple AND/OR operations. Here’s the truth table:

Instead of looking to a UDF to perform domain integrity, we can use a simple logical disjunction instead. So, instead the CHECK constraint might read:

The same unrestricted query looks like this:

SQL Server parse and compile time:

CPU time = 15 ms, elapsed time = 49 ms.

SQL Server parse and compile time:

CPU time = 0 ms, elapsed time = 0 ms.

Table ‘Product’. Scan count 1, logical reads 1012, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:

CPU time = 16 ms, elapsed time = 13 ms.

(504 row(s) affected)

113 ms compared to 13 ms?!? The difference between the CHECK constraint using an UDF and one using a simple NOT P OR Q is separated by almost a factor of 10. This is a simple table with a tiny amount of data, 504 rows. Imagine what this looks like at scale with millions of rows. A little bit of logic can save a lot of time. Moral of the story? Where and when you can, use logic and relational algebra, it will usually yield better database performance.

I know I linked to it in this blog post already but I want to call it out again, please read Gail Shaw’s post on UDFs. It’s very good: http://sqlinthewild.co.za/index.php/2009/04/29/functions-io-statistics-and-the-execution-plan/.

Oh, and I think a bike blade might be a type of fender. At least, that’s what my searches on REI.com tell me.

If you’re on a 32-bit system, you’ll want the 32 bit equivalents available below these options. Once you’ve downloaded those files, find SQLFULL_x64.ENU_Install.exe and execute it.

The software will unpack and create an install directory.

Find the install directory that the software unpacked to, named SQLFULL_x64_ENU, click inside it and double click on the bootstrapper file called SETUP.

A window called the SQL Server Installation Center will open up. The first option is Planning. If you are not familiar with SQL Server and want to go through a few of the options there, feel free. Once you are ready to install, click on the Installation link on the left hand portion of the window. The usual selection here is select, “New SQL Server stand-alone installation or add features to an existing installation”. Select that option.

The next window will just show the progress of SQL Server performing some sanity checking. If there’s any errors here, you’ll want to view the detailed report and see what is wrong with your setup. This isn’t that common.

Once done, click OK. The setup process will ask you for a key. If you have a key, you may enter it, otherwise you may select either “Evaluation” or the SQL Server Express option. For our purposes, just select the evaluation option and hit Next.

Accept the license terms and hit Next.

After that, more preparation in the way of setup files will occur. Once that is done, hit Install.

SQL Server Setup will perform some additional sanity checks to make sure there’s no problems with your computing environment. Everything should check out. If it does, hit the Next button to continue.

Now we’re getting to the point where we get to start making some choices with respect to our installation. Since we want to get the full SQL Server experience, select the first option, “SQL Server Feature Installation” and hit the Next button.

Since this is our first installation of SQL Server 2012 (that is why you’re following this guide, right?), we’ll likely want to play with all the available options. If that is the case, hit the “Select All” button below the Features window. If not, you’ll want to scan through the features and cherry pick the ones you wish to install. When you’re comfortable with your choices, hit the Next button.

More sanity checking. If you’re curious, click, “Show details”, elsewise hit Next to continue.

If you have more than one copy of SQL Server installed (in my case, I have both a copy of SQL Server 2008 R2 and a copy of SQL Server Express), you’ll need to create a named instance for your SQL Server 2012 installation. In this case, I imaginatively called mine SQL2012. If you’re installing SQL Server for the first time, it will make your life a lot easier if you just use the default instance.

After you hit Next, SQL Server will want to make sure that you have enough room on disk for your installation. Review the disk usage summary and hit next if you have enough room. You should.

SQL Server 2012 Setup will now ask you for the account names and collation specification. If this is a production box, you’ll want to follow your organization’s service account best practices. If you’re installing this on your home computer for testing and learning purposes, you may just wish to accept the defaults here and hit Next.

The database engine configuration options are up next. Under the Server Configuration tab, select the Authentication Mode you wish to have. I usually pick Windows authentication mode for my test installations unless I need Mixed Mode. You’ll want to add whatever accounts you wish to have administrative access to your SQL Server 2012 installation. Typically, it’s at least the account you’re installing the software from if not others as well. Once that is done, click the Data Directories tab.

Here you may change where SQL Server stores various files as well as the defaults for when you create new databases. I’m on a laptop with just once hard drive, the C:\ drive, so I’m going to keep the folders as they are. Many times on a production server, you’ll be changing these fields here. Once you’re done, click the FILESTREAM tab.

Starting with SQL Server 2008, SQL Server has been able to include unstructured data as part of a logical database structure via FILESTREAM. This addresses the common situation where images or documents may be held on the filesystem while referencing paths and attributes are held within the database. Learning how to work with FILESTREAM is highly recommended, so I would suggest turning it on. Once done, click the Next button.

Since were installing SSAS as well, select the mode you wish, Multidimensional and Data Mining Mode or Tabular Mode. Make sure to add an account that will have administrative permissions as well, usually at least the one you’re installing from. Then click the Data Directories tab.

Here, if you wish to change where SSAS files are located and default locations for new ones, modify the paths to where you wish those files to be located. Once finished, click the Next button.

Next up is the Reporting Services Configuration window. I typically just select the defaults here, “Install and configure” for Reporting Services Native Mode and, “Install only” for Sharepoint Integrated mode. Select the option that makes sense to you and hit Next.

Next up, SQL Server 2012 Setup will ask you about how to set up the Distributed Replay Controller. I have yet to explore Distributed Replay but from the documentation, you’d want to use it when:

• You want to evaluate application compatibility. For example, you want to test SQL Server and operating system upgrade scenarios, hardware upgrades, or index tuning.
  
• The concurrency in the captured trace is so high that a single replay client cannot sufficiently simulate it.

Specify the users you wish to have permissions for the service and hit Next.

Next up, specify the distributed replay client. I just set up my own computer in this case since this is a stand alone installation.

Next up, select the options you wish to have for error reporting. I tend to give Microsoft access to my errors. I’m not particularly paranoid about that kind of information. Select the option that aligns best with your own personal persuasion.

SQL Server will then wish to perform more sanity checking. If your system passes muster, click Next.

SQL Server will give you one final review window before it installs. Review everything here and then click Install and it’s off to the races.

Walk away, take a nap, go on a walk, do something and once you’ve returned, hopefully the window below will be waiting for you. Congratulations! You’ve successfully installed SQL Server 2012. Smile to yourself and click the Close button.

Just to make sure that everything is in working order. Find your SQL Server 2012 installation and select SQL Server Management Studio.

Once it opens, it’ll ask what server you wish to connect to. Here, I type in the name of SQL Server 2012 instance name and click Connect. If you have a default instance, you can just go to localhost to connect.

Once you’ve successfully connected, you’ll have a screen like mine below sans the AdventureWorks2012 database. To get the AdventureWorks2012 database, go to the Adventures Works for SQL Server 2012 Codeplex page. You’ll want to attach the database file once you’ve downloaded it. If you’ve never done that before, follow the tutorial here.

Once you have the AdventureWorks2012 database installed, it’s time to play! If you’ve never played with SQL Server before, you may wish to get started here. Happy querying!

In the next window that pops up, name the connection (here we just called it Localhost) and then click on the Edit button.

In the window that pops up, enter the server and the database that you would like to connect to.

You can click the Test Connection button if you wish but really, if you can select the database, you can connect to the database. Click OK twice to create the shared data source.

Once that is done, we will want to create a report. As usual, you can just right-click on Reports to get the menu. If you click on, “Add New Report”, it’ll take you to the Add New Report Wizard. I prefer to just create a blank report and create from there. To do that, click on Add -> New Item…

Select the Report option and give it a name. I named mine, Top 500 Sales Around the World.

Next, click on your Toolbox pane, select the Map object, and drag it over to your report.

When you drag it over, a new window will pop up with options for adding a new map layer. Select the option for a SQL Server spatial query and hit, “Next”.

The next window asks if you wish to choose an existing dataset or create a new one. We will want to create a new one (it’s at the bottom). So select that option and then hit the Next button.

Click the “New…” button on the next window that pops up to create a new data source.

On the Data Source Properties window, name the connection something sane and then select the, “Use shared data source refence” option and in the dropdown list, select the shared data source we created before. Click OK.

Then click Next.

The next window that pops up will want you to create a query. Select, “Edit as Text” and enter the following query:

SELECT TOP (500) Address.SpatialLocation

FROM Person.Address AS Address INNER JOIN

Sales.SalesOrderHeader ON Address.AddressID = Sales.SalesOrderHeader.ShipToAddressID

Click Next. SSRS will detect that the values we are using are points. With the points themselves just being points in space, you’ll want some form of underlying map to plot them on to. At the bottom, select the option to add a Bing maps layer and click Next.

Select the type of marker map you want to use and click Next.

Select your final options such as theme, marker types, and color options and then click Finish.

Once that is done, you can click on the Preview pane and see your shiny new SSRS map!

Please note that while my map is called Top 500 sales locations, it isn’t a top 500 in the usual sense (500 highest grossing sales). It’s merely the first 500 rows in the Person.Address table that have matching values in the Sales.SalesOrderHeader table. Building a map in SSRS is impressively easy.

We would like to extract geospatial information from the AdventureWorks database and plot it in Mathematica. The AdventureWorks database ships with geographic data contained in the Person.Address table.

Let’s assume that we want to extract sales information regarding where products are being shipped to from the AdventureWorks database. If we create a database diagram in SQL Server starting with the Person.Address table and add related tables, we will have a diagram similar to the one below.

In this diagram, we can see that the Person.Address table and the Sales.SalesOrderHeader table are related to each other by a foreign key relationship.

With the column and referential information we have in hand, we’re ready to build a candidate query to extract this information. In this particular case, we’re only interested in plotting lat/long points and so we will use the Lat and Long from Microsoft’s extended methods for the geography data type.

The query itself is a simple inner join pulling lats and longs from the Person.Address table and joining them on the SalesOrderHeader table.

SELECT DISTINCT TOP 500 SpatialLocation.Lat AS Lat, SpatialLocation.Long AS Long

FROM Person.Address INNER JOIN Sales.SalesOrderHeader

ON Person.Address.AddressID = SalesOrderHeader.ShipToAddressID

The output below should be what you get:

With this data in hand, it’s time to move over to Mathematica. We will want to connect to SQL Server using Database Link. Once that is done, we will want to set up a SQLExecute to use the connection we have built and execute the query above. My Mathematica notebook looks like the following:

Next, we will need to use GeoGridPosition and GeoPosition to graph the points on a map. To do that, we will use the following:

Graphics[{Red,Point/@Map[GeoGridPosition[GeoPosition[#],”Mercator”][[1]]&,{spatialquery},{2}],Gray,Polygon[Map[GeoGridPosition[GeoPosition[#],”Mercator”][[1]]&,CountryData[#,"Coordinates"],{2}]]&/@CountryData["Countries"]}]

The output should then be as follows (click picture for larger size):

It looks like most of our sales are going to the west coast of the United States, the east coast of England and the east coast of Australia.

As a side note, this post couldn’t be possible without the very helpful users at the Mathematica StackExchange. I’ve never worked with geospatial data in Mathematica or SQL Server before and I wanted to learn about how to do this in Mathematica and found myself without the ability to chart a direction. I posted a question and within hours the answers were all pouring in. It’s a pity I can only accept one reply as the answer. The Mathematica code I’m using in this post is borrowed from the accepted solution to my question here.

This walk through connects to the SQL Azure AdventureWorks database which you can download here.

The first thing to do is download the JDBC driver and unpack it to C:\Program Files\Microsoft SQL Server JDBC Driver 3.0\.

Once the driver is unpacked, I navigated to sqljdbc_3.0 and removed the sqljdbc.jar file and left sqljdbc4.jar. When I was working with Wolfram support (who, by the way, are extremely knowledgable and professional), we had some issues with ClassPath and the two drivers. The way we resolved this is by removing that file.

Once you’re just left with sqljdbc4.jar, open up Mathematica and create a new notebook file. The notebook will require both Jlink and DatabaseLink so use the Needs[] command to import both of those.

Next, we’ll need to add the Microsoft JDBC driver to the class path so execute:

AddToClassPath["C:\\Program Files\\Microsoft SQL Server JDBC Driver\\sqljdbc_3.0\\enu\\sqljdbc4.jar"];

Like so:

Then execute:

LoadJavaClass["com.microsoft.sqlserver.jdbc.SQLServerDriver"];

Like so:

Now it’s time to connect to SQL Azure with Mathematica. The command and parameters you’ll use look like the following:

queryazure = conn=OpenSQLConnection[JDBC["com.microsoft.sqlserver.jdbc.SQLServerDriver","jdbc:sqlserver://<SERVER>.database.windows.net;databaseName=AdventureWorksLTAZ2008R2;user=<USERNAME>@<SERVER>;password=<PASSWORD>;"],”Username”->”<USERNAME>@<SERVER>”,”Password”->”<PASSWORD”]

My connection appears as the following (I’ve blotted out the sensitive information):

Once the connection is made, you can confirm your connection by executing

SQLTableNames[queryazure]

Finally, let’s query for something specifically. Below is a screenshot looking at the SalesLT.Product table via the web interface:

One may can also connect with SQL Server Management Studio 2008 R2 as well:

The query we will want to execute is a simple one: “SELECT * FROM SalesLT.Product”. To do so, we just execute the following:

query =SQLExecute[queryazure, "SELECT *

FROM SalesLT.Product"]

The output is as follows:

That’s it! Enjoy playing with Mathematica and SQL Azure! There’s lots of blog posts on different things to do and they can be applied to SQL Azure just the same. Some of my favorites are: Graphing a Hierarchy from a Common Table Expression Using TreePlot, Graphing Foreign Keys in SQL Server Using Mathematica, and Foreign Keys as an Incidence Matrix: A High Level Look.

Finally, I want to credit Wolfram support for their assistance in getting me to connect. They worked with me in fixing my erronious JDBC configuration in Mathematica. Without them, this post wouldn’t be possible. Thank you Wolfram support!

To start, the simple graph of the finite key relationships present in the AdventureWorks database is already a cycle matroid. This is a very well known result as all finite graphs are cycle matroids. The independent sets in a cycle matroid are the edges that do not form a closed path.  Arguably, the cycle matroid derived from the AdventureWorks database graph may have some interesting properties.

Instead of investigating the properties of this cycle matroid, we will investigate the AdventureWorks database as a transversal matroid. The definition of a transversal matroid in “Matroid Theory” by James Oxley is as follows:

A way to visualize transversals is via bipartite graphs:

The AdventureWorks database actually works as a great candidate for a transversal matroid. The family of subsets of the AdventureWorks database is the schemas. The AdventureWorks2008R2 database has the following schemas: dbo, HumanResources, Person, Production, Purchasing, and Sales. It’s easy to query the database for its schemas:

SELECT DISTINCT SCHEMA_NAME(schema_id) FROM sys.tables

The expected output is shown below.

To visualize the relationship between tables and schemas, we will need to create a bipartite graph of the relationship. We will create a connection to the database the usual way. Once that is accomplished, we will need to run the following command:

The reason we use CASE in the T-SQL statement is because there’s a table named Person too. So to take care of the fact that there’s a schema and a table of the same name, we just rename it. An partial listing of the output is show below:

We will need to combine the two columns into something Mathematica will like to work with for graphing.

I tried having the SQL query seamlessly put out columns of the form “SpecialOffer” -> “Sales”. While the query executed the way one would expect in SSMS, the parser Mathematica uses choked on it. So here we are, inelegantly combining the results. It is what it is. Perhaps I’ll find the trick.

We apply the custom function Combine to the query result set.

Finally, it’s time to see something worth looking at. The command below:

Returns:

To see the entire graph, click on the image. It’s very large.

While we’ve generated a great looking image of the relationship between schemas and tables in the AdventureWorks database, we have not yet described the matroid yet. In the second part of this series, we will generate the maximal independent sets to describe this matroid. I’m looking forward to it!

The graph from our previous post is below:

It really is a pretty constellation of vertices and edges. It’s possible to go a few steps further and manipulate this captured information in other ways. For example, one could create an incidence matrix of the graph. An incidence matrix where the columns are the edges and the rows are the vertices of a graph. If a vertex i is connected to an edge j, then the i,j entry of the incidence matrix is 1, otherwise, it’s marked 0.

In our previous example, we created a graph named fkgraph by executing:

fkgraph = Graph[querygraph]

To retrieve an incidence matrix from this graph, we may use the IncidenceMatrix function in Mathematica. Once executed, we may execute:

IncidenceMatrix[fkgraph]//MatrixForm.

If we do not utilize the PostFix function (//) to format IncidenceMatrix function with the function MatrixForm, we will get a sparse array like below.

A partial output of the desired output is captured below:

If we look above at the SparseArray output, we can immediately see that the number of rows of the incidence matrix is sixty-seven. That is, there are sixty-seven points in the graph. Consequentially, we know that there are sixty-seven tables with foreign key relationships in the AdventureWorks database as each point represents a table. There are simpler ways of deriving that information but as one proceeds to more abstract layers, it’s good to remember what one is actually working with.

What about the matrix itself? What is the rank of the matrix? To understand the rank of this matrix, we will use the Mathematica function MatrixRank.

MatrixRank[IncidenceMatrix[fkgraph]]

The output is:

Sixty-seven. Who knew? It’s a well known fact that the column rank and the row rank of a matrix are equal. Sixty-seven is the number of rows (points) in the matrix and eighty-six is the number of columns (edges). This would imply that the difference between total columns and the size of the column space is the number of dependent columns. Dependent columns are, in this representation, different choices one could make to JOIN one table with another.

The matrix itself is rather overwhelming. To get a better at a glance view of what the matrix looks like, we can use the MatrixPlot function.

The orange squares represent the value of one and the white of zero. In this sense, we have a rough understanding of the dispersion of ones and zeroes throughout the matrix.

I hope I’ve introduced enough tools in Mathematica to get one started with manipulating datasets and beginning to derive a deeper understanding regarding their properties. The topic is very deep and there’s much to learn and discover.

Picking up where we left off, we just created a multigraph of the foreign keys in AdventureWorks that looked like this:

The next thing that we’d like to be able to do is take this graph and make it something that we can perform further operations on to gain a deeper understanding of our database structure. To start, we need Mathematica to be able to create a graph object out of the result set. This means the graph must no longer have parallel lines. It must be a simple graph. The simple way to do this, especially since we no longer need the foreign key names is to massage the query a little bit:

SELECT DISTINCT OBJECT_NAME(f.parent_object_id) AS TableName,

OBJECT_NAME (f.referenced_object_id) AS ReferenceTableName

FROM sys.foreign_keys AS f

INNER JOIN sys.foreign_key_columns AS fc

ON f.OBJECT_ID = fc.constraint_object_id

By doing this, all the duplicate rows will be removed.

A quick scan and comparison of the two queries will confirm that the total number of repeated tables in the first query was five and that the duplicates have been removed. I would love, love, love to craft a query that returns distinct pairs of values along with columns with duplicate information but I don’t have the requisite skill to craft that query in an acceptable amount of time. I intend to fix that. It’s an interesting problem. Now that the duplicate values have been removed, we may perform the typical operations that we used before. To begin, we open up the notebook we created before or input and execute the commands as shown below:

Once completed, the next step is to create the substitution function in Mathematica. To make the undirected edge symbol in Mathematica, hit the ESC key, type, “ue” and hit ESC again. <-> suffices as well if you like ugly.

And, of course, apply to the result set from SQL Server:

The set up is complete, next we will just apply Graph[] to the modified list:

The first question we may get the answer to now that the foreign key relationships in AdventureWorks are represented in a simple graph is what is the maximum minimum number of joins one must perform to join any one table in the database with another? What about the minimum maximum? To do this, we will want to calculate the graph diameter and graph radius of the graph, respectively. The answer turns out to be nine and five. Who knew?

What about knowing which tables have the most or least amount of graph eccentricity? Very easy to answer:

The central most tables in AdventureWorks are Document, PurchaseOrderHeader, and SalesOrderDetail while the most isolated tables are CountryRegionCurrency, PhoneNumberType, Illustration, Culture, ProductDescription, and SalesTaxRate. It certainly beats trying to figure it by looking at the diagram snippet below and trying to figure it out.

What’s the real world consequence of this? Using Mathematica in this respect can reduce the amount of time it takes to understand the high level structure of your database. Specifically, some poorly running queries may be associated with extensive use of joins. In his paper, “Query Optimization“, Yannis Ioannidis asserts,

“The memory requirements and running time of dynamic programming grow exponentially with query size (i.e., number of joins) in the worst case since all viable partial plans generated in each step must be stored to be used in the next one. In fact, many modern systems place a limit on the size of queries that can be submitted (usually around fifteen joins), because for larger queries the optimizer crashes due to its very high memory requirements. Nevertheless, most queries seen in practice involve less than ten joins, and the algorithm has proved to be very effective in such contexts” (referring to dynamic programming algorithms).

It’s worth noting that the paper was written in 1996 so many things have changed but the fundamental issue of joins being costly will remain true, especially as we continue to experience the explosive data growth that we have. Performing these analytical steps is no silver bullet. Much of performance tuning is correlating information from a variety of sources to understand what database users are looking for and how SQL Server is trying to respond to it.

And turn it into something that looks like this:

The challenge is to extract a result set that will give us what we need. Fortunately for us, great minds can show us the way. Pinal Dave (SQLAuthority.com) whipped up a tidy query that forms the basis of what we will use. The query we will use has some slight modifications from the original on Mr. Dave’s blog:

SELECT OBJECT_NAME(f.parent_object_id) AS TableName

,OBJECT_NAME (f.referenced_object_id) AS ReferenceTableName

,f.name AS ForeignKey

FROM sys.foreign_keys AS f

INNER JOIN sys.foreign_key_columns AS fc

ON f.OBJECT_ID = fc.constraint_object_id

The result set for AdventureWorks2008R2 should appear akin to what is below:

Next, let’s get this all into Mathematica. Make sure to set up the notebook file to connect to SQL Server like so:

Add in the query typed out above:

The output should look like the partial results below:

The Mathematica function we intend to use to visualize the foreign keys in the AdventureWorks2008R2 database is GraphPlot[]. Like TreePlot [], a function we used in a similar post, we will need to massage the result set into something Mathematica can use. If we wish to label the edges with the names of the foreign keys then GraphPlot will need to see entries akin to {u -> v, “w”}. To do this, we will use the Function[] ummmm function.

Once that is done, we will need to apply the function to the result set from SQL Server.

At this point, we’re ready to graph the foreign keys using GraphPlot.

It’s worth noting that the resulting multigraph is very, very busy. Here’s a screenshot of the graph expanded and a corner zoomed in on.

It’s possible to vertex label as well but imagine how cluttered the graph will be. Perhaps we want to abstract out the labels and just see the general structure of foreign keys in the database. We merely need to built a new function that does not have edge labeling and use that one instead.

When the function is applied to the result set, we get a flat table of relationships perfect for GraphPlot.

Once that is passed to GraphPlot, the resulting graph ensues:

There it is! All the foreign keys in the AdventureWorks2008R2 database seen from a bird’s eye view. So what next? Are we able to perform any mathematical manipulation on this? We’ll investigate that in part two. Thanks for reading!

One of the great powers of CTEs is that they trivialize hierarchical queries. A common example is querying AdventureWorks to build a list of who reports to whom. Take the following query, shamelessly yanked from SQL Lion (with a tiny modification):

WITH EmpDetails (EmployeeKey, FirstName, LastName, ParentEmployeeKey,

PFirstName, PLastName, EmployeeRank, [Status])

AS

(

SELECT

EmployeeKey,FirstName,LastName,ParentEmployeeKey

,CAST('NULL' AS VARCHAR(50)) AS PFirstName

,CAST('NULL' AS VARCHAR(50)) AS PLastName

,1 AS EmployeeRank,[Status]

FROM dbo.DimEmployee

WHERE ParentEmployeeKey IS NULL

UNION ALL

SELECT e.EmployeeKey,e.FirstName,e.LastName,e.ParentEmployeeKey

,CAST(CTE_Emp.FirstName AS VARCHAR(50)) AS PFirstName

,CAST(CTE_Emp.LastName AS VARCHAR(50)) AS PLastName

,CTE_Emp.EmployeeRank + 1 AS EmployeeRank

,e.[Status]

FROM dbo.DimEmployee e

INNER JOIN EmpDetails CTE_Emp

ON e.ParentEmployeeKey = CTE_Emp.EmployeeKey

)

SELECT * FROM EmpDetails WHERE [Status] IS NOT NULL ORDER BY EmployeeRank

If we query the AdventureWorksDW2008R2 database, we should get a similar result to the result set below:

Reading the result set, we can see that Ken Sánchez reports to no one as his ParentEmployeeKey is NULL. Throughout the rest of the table, we can see we have individuals that have someone else they report to. In tabular format this is difficult to read and even harder to visualize.

Enter Mathematica and TreePlot[]. We want to take the essential data from the above output and create a visual representation. To start, we will want create a database connection in our notebook (.nb) file. This is done the usual way with DatabaseLink.

Take care to note that for the purposes of this example, we are connecting to the AdventureWorksDW2008R2 database and not AdventureWorks2008R2. Once connected, we will want to use the above query with a small modification.

We modified the SELECT * from the first query to SELECT EmployeeKey, ParentEmployeeKey. This is due to the fact that the other columns are extraneous to our purpose and will only create problems if we keep them in the result set. Once we run the command, we should receive a result set that appears as follows (the image is cropped):

If we look at the TreePlot documentation, we note that our list isn’t quite in a usable state so we will have to massage the data some. The first thing we will do is define a function that will take two parameters u, v, and return u -> v. To do this, we will use the Function[] function in the following manner: Unite = Function[{u,v}, u -> v]

I’ve named my function Unite. It’s a terrible name. Feel free to name yours better. Once the function is built, we need to apply it to the list. To do this, we will use Apply[].

We’ve used shorthand here with the three @ signs. The reason we’ve done so is that the default behavior of Apply would be to apply the “Unite” function at the top level of the list. We want it to apply at one level beneath that. The three @@@ signs is shorthand for doing exactly that. The documentation for Apply discusses it. Also note that the Apply function stripped the sublists out of the list, giving us a litany of relation rules ready for TreePlot. To use TreePlot, merely pass the variable for the relation rules and any options needed. In this example, we want to label our vertices.

It appears that we have four discrete trees in our hierarchy! While this would seem to be unexpected, a simple verification of the data does show that this is not inaccurate. The trees are quite small and very busy so if we select them, click, and drag, we can see them in better detail.

That’s it! We’ve just used a common table expression to query a database for hierarchical relationships and then used Mathematica to graph it. Play around with it and leave any comments you might have. Thanks for reading.