As illustrated in the table above declarative database development is central to the SSDT product. In looking at the table above arguably the differences in connected database development between SSMS and SSDT will be the most common point of conceptual friction for new SSDT users (I know it was for me when I first joined the team), so I’ll start there.

Connected Declarative Database Development – The Happy Path

One of the things that database developers will notice when firing up SSDT for the first time is the addition of the SQL Server node in the Server Explorer. The following screenshot illustrates how this looks in SSDT CTP3 integrated with Visual Studio 2010 Ultimate and connected to a SQL Server Code Name “Denali” CTP 3 instance:

The SQL Server node has been purposefully designed to have an experience that closely mirrors SSMS. This was done to allow SQL Server database developers the luxury of using their existing SSMS “muscle memory” in SSDT. However, the experience in the SQL Server node has been optimized for the most common database developer tasks. As such, not all SSMS features are available from the SQL Server node. This reflects the product philosophy where SSMS is the manageability tool for DBAs and SSDT is focused on developers. Our intent with the SQL Server node was trying to target the sweet spot where most developers will not need to leave the Visual Studio shell most of the time while they are developing T-SQL code. Feedback on our success on this would be most appreciated.

Unlike SSMS, SSDT’s default connected development experience is declarative. We can see this exhibited in the following screenshot where I’ve navigated to the Customer table in the Northwind database and double-clicked on it in the SQL Server node:

By default tables are opened in the new SSDT Table Designer. The Table Designer is very cool because it allows an optimized experience for developing SQL Server tables. As a developer I can use the design grid in the top pane if that’s the way I prefer to work or I can use T-SQL code in the bottom pane. Both panes are synchronized so I can leverage both if that’s the way I like to work (more in-depth posts on developing using SSDT will be coming soon). Regardless of the pane used, the T-SQL code remains the source of truth (this is true in every feature of SSDT).

Declarative connected development is implemented using SSDT’s Power Buffer technology. The easiest way to think about Power Buffer is to imagine that your connected development is done in a sort of database scratch pad. Using Power Buffer you can alter table structures, rename columns, add new tables, create new FKs, write sprocs, etc., all without actually altering the physically executing database. As an example, the following screenshots illustrate me adding a CustomerSegmentation table and adding a FK from Customer to Customer segmentation using Power Buffer:

Notice how all the code in the above screenshots are based on CREATE (i.e., you don’t see an ALTERs anywhere in the code). This is a core idea in SSDT. When I develop my database I target the desired end shape of the structures without worrying about the current shape of those structures. When the time comes to alter the physically running database I tell SSDT to take my scratch pad containing how the database should look and figure out how to change the running database to match my scratch pad. Clicking the Update Database button (which is present in all Power Buffer windows) tells SSDT to do exactly this. The following screenshot illustrates the result of requesting SSDT to update the Northwind database:

In looking at the Preview Database Updates dialog it is worthy to note that a Power Buffer scratch pad is scoped on a per-Database basis. This is a critical concept because, as we’ve seen above, multiple Power Buffer document windows actually operate over the same scratch pad (i.e., each document window is a viewport into the same scratch pad). As such, clicking the Update Database on any Power Buffer window automatically incorporates all the changes from any dirty document window that is a viewport into the same scratch pad. In our example, I clicked Update Database on the Customers window and the changes from the CustomerSegmentation window were automatically incorporated.

Taking a closer look at the Preview Database Updates dialog we can see the net result of SSDT incorporating all the scratch pad changes and comparing them with the actual running database. As listed in the dialog, SSDT has determined that the Customers table needs to be altered (to add the new CustomerSegmentation column), that a new table needs to be created (CustomerSegmentation), and that a new FK needs to be created. The SSDT engine is very intelligent. The algorithms involved are deliberately engineered to produce changes that have minimal adverse impacts on the running database (e.g., using sp_rename to change the name of a column) and also prevent inadvertent data loss. Just in case you are still skeptical about how SSDT does things, the dialog offers the “Generate Script” button which allows you to see exactly what T-SQL SSDT will send to the running database to update it’s structure . Since I trust the product, I’ll just go ahead an click “Update Database” and voila! My running Northwind database is updated. No fuss, no muss.

Next Time

Having taken a very quick look at the happy path through SSDT declarative connected development, the next installment in the series will take a look at some of the alternate paths for connected development – namely how do you work imperatively against live databases with SSDT and some of the gotchas that arise when trying to use Power Buffers windows like SSMS-style T-SQL document windows.

As always, feedback much appreciated.

Until next time, thanx for reading!

After a lot of hard work by the team, the CTP3 bits for SQL Server Developer Tools, Codename “Juneau” (SSDT) are now available for everyone to take for a spin. The SSDT install experience is based on Microsoft’s Web Platform Installer (Web PI) and lays down all the SSDT goodness you need, including the new LocalDB engine. I encourage everyone to take the bits for a spin and don’t hesitate to provide feedback to the team – either directly to me or via the SSDT Forum.

With the CTP3 bits now public I can continue my series on thinking about SSDT since the screenshots are no longer super-secret.

For convenience, here are some helpful links:

• Main SSDT page in Data Developer Center
• SSDT Download/Install Page
• SSDT Forum
• SSDT Team Blog
• SQL Server’s Connect Page

Enjoy the bits and we look forward to feedback!

Folks that are familiar with Visual Studio 2010 SQL Server database projects will find most of this post to be old hat. Additionally, the contents of this post are the opinions of one PM and don’t reflect the opinions of my Architect, GPM, GM, or Microsoft as a whole.   ;-)

</Disclaimer>

When I first joined the team, it took me a bit of time to grok SQL Server Developer Tools, Codename “Juneau” (SSDT). I like to think that I’m a relatively intelligent guy, but in the beginning I just had a mental block on the product. I just didn’t “get it”. It took some time, and patience, from the other members of the team to get my head in the right space. At first this worried me, because if I didn’t get SSDT how would Microsoft expect our customers (many of which will have backgrounds like mine) to get it?

Enter the first of a series of posts. I’m guessing that a lot of folks will be in a similar spot where I was when they start taking a look at/playing around with SSDT. I’m not going to lie, if you are like I was (i.e., SSMS is/has been your SQL Server development tool) there’s a learning curve to SSDT. However, now that I’ve scaled the learning curve I can honestly say that the effort is well worth it – so much so that if I started consulting again tomorrow I would be advising my clients to adopt SSDT. The goal of these two posts is to begin the process of flattening the SSDT learning curve.

Being a big fan of Joel Spolsky, I’m going to use concepts from his most excellent book on UI design in describing, IMHO, the best way to think about SSDT. In Joel’s book the concepts of program and user models are key in designing a quality user experience. Not surprisingly, understanding SSDT in light of these concepts goes a long way in groking how to use SSDT and the UI decisions we’ve made in the product. Given the importance of these concepts, I’ll provide some definitions paraphrased from Joel’s book:

User model: The collection of expectations a user has regarding how to interact with a new software user interface, resulting in the user’s mental model of how the software should function.

Program model: How the software actually functions (i.e., how it is coded), which is a reflection of the user model of the team that developed the software.

The above concepts are simple, intuitive, and powerful. For example, given that the almost universal user model for word processors is WYSIWIG, a team that writes a revolutionary new word processor that isn’t WYSIWIG is going to need to provide great facilities/guidance for their customers to shift their user models to the new program model.

When I started on the SSDT team my user model for developing SQL Server databases was formed by the program models of the development tools I used. This is only to be expected because the program models of SQL Server tooling has essentially remained the same from SQL Server 6.0 through SQL Server, Code Name “Denali”. The following screenshots illustrate this model from SSMS 2008 R2:

The program model of SQL Server tools is imperative development. That is, when using SSMS the database developer crafts T-SQL code instructing the SQL Server engine on what exactly to do to create, alter, drop, etc. the desired database objects. This is worthy to note as writing T-SQL queries is, by way of comparison, declarative – the database developer tells the SQL Server engine what she wants done (e.g., SELECT * FROM Customer) and the engine figures out how to do it. As any application developer can attest, traditionally you spend a lot more time doing imperative SQL Server development early in the development lifecycle than you spend doing declarative development. Given the tools, it is easy to see how the typical developer’s user model for developing and querying SQL Server databases came to be in alignment with the underlying program model of the tools.

Because it serves my purposes for this post (which will be come clear in just a bit), I would also like to mention that SSMS supports two methods of performing database development – Connected and Project. The first is a no-brainer that every SQL Server developer is familiar with and is illustrated by the screenshots above. The second is less well-known (I only learned about my self about a year and a half ago) and is illustrated by the following screenshots from SSMS 2008 R2:

From a user/program model perspective, working with SSMS projects to develop a database isn’t that much different from doing connected development – the model is still imperative in nature.

All of this is important in thinking about SSDT because I can now construct the following table that lists the typical SQL Server database developer’s user model for various SQL Server database development activities and compare these with the user models needed to properly grok SSDT:

As the table illustrates, we’re changing some things in SSDT. However, as I mention above, I’m fully convinced that we’re changing them for the better.

The subject of my next post will be to talk about the decisions we’ve made in SSDT based on the table above and how these decisions manifest in the UI.

Until next time, feedback most welcome and thanx for reading.

Paper is located on my skydrive:

As this is my inaugural post on SSDT, I figured I would talk a bit about my background and the philosophy I will be following in subsequent SSDT posts (hopefully this doesn’t seem overly egomaniacal). Additionally, there will be a collection of links for folks to presentations on SSDT so they can see the bits in action.

About Me

I’m a Program Manager on the SSDT team with a tenure of around 8 months. Previous to the SSDT team I worked for 10 months on the Oslo Repository team focusing on the UML Domain and spent a year in Microsoft IT as an Enterprise Architect. Before coming to Microsoft in October 2008 I worked for several years as a consulting software/solution architect for medium-large IT shops. Before that I spent a number of years working as an architect for a Fortune 500 insurance company. I’m not a T-SQL expert, nor am I an expert on administering SQL Server. However, I have designed and built many enterprise systems using SQL Server and I am intimately familiar with the enterprise space. Just for the sake of full disclosure, I’m a unabashed UML junkie, OOA/D bigot and a big fan of many Agile practices (e.g., Continuous Integration), but not necessarily a fan of all Agile methodologies (e.g., XP).

My SSDT Blogging Philosophy

The philosophy I will be taking regarding my SSDT blogging is this – if I started consulting again tomorrow how would I advise my clients to think about and adopt SSDT to make their SQL Server development better, cheaper, and faster. This view should, hopefully, give an air of credence to my posts. Quite frankly, a product as significant as SSDT isn’t going to be all things to all people in every situation. I fully plan on blogging about the features of SSDT that would appeal to my previous enterprise IT customers in a broad range of scenarios.

OK, enough blather. Some links to where you can see the SSDT bits in action are listed below. The subject of my next post will be how to think about the SSDT program model so as to get the most out of the product. Until then, feedback most welcome.

SSDT Links

• TechEd Atlanta, May 2011:
  • https://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV207
  • https://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV314
• TechEd Europe, Nov 2010:
  • https://www.msteched.com/2010/Europe/DAT314

As part of this logical, and necessary, business decision I’ve accepted a PM position working on one of these “big bets” – the next generation of development tools for SQL Server database architects and developers. While as a unrepentant UML junkie I’m a little sad to see development on the UML Domain stop, I would be lying if I said I wasn’t totally stoked for my new gig. As you might imagine, a “Big IT” modeling junkie like myself has a lot of hands-on experience modeling, designing, and developing SQL Server databases. As such, the opportunity to influence Microsoft tools in this space appeals to my ego.

To this end, I’m hoping to fire up the blog posts again and target topics related to developing SQL Server databases and database-centric applications. Additionally, I’ll also be trolling for any community feedback regarding our current feature set for doing SQL Server database development. All feedback will be most welcome, especially feedback on where we need to improve.

As always, thanx for reading.

Enjoy!

Querying Class Attributes

In Part 1, I walked through the construction of a query to retrieve the class attributes for the Individual class from the UML Domain. In keeping with the philosophy of this series, the results are geared to mimic the data typically displayed for UML class attributes on a prototypical UML tool’s diagram canvas. The following T-SQL query and result set summarize this work:

   1: select C.[Id] as ClassName, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        P.[Id] as PropertyId, P.[Name] as PropertyName, P.[Visibility], 

   3:        T.[Id] as TypeId, T.[Name] as TypeName

   4: from [Microsoft.Uml2].[Classes] C

   5:     inner join [Microsoft.Uml2].[Properties] P on (C.[Id] = P.[Class])

   6:     inner join [Microsoft.Uml2].[Types] T on (T.[Id] = P.[Type])

   7: where C.[Name] = 'individual' and C.[Folder] = [Repository.Item].[PathsFolder] ('MyModels/FourPlusOne')

Querying for Class Operations

In Part 2, I walked through the construction of a query to retrieve the class operations for the Individual class from the UML Domain. As before, the results are geared to mimic the data typically displayed for UML class operations on a prototypical UML tool’s diagram canvas. The following T-SQL query and result set summarize this work:

   1: select C.[Id] as ClassName, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        O.[Id] as OperationId, O.[Name] as OperationName, O.[Visibility], O.[ClassPosition],

   3:        Params.[Id] as ParameterID, Params.[Name] as ParamName, Params.[Direction] as ParamDirection,

   4:        Params.[OwnerFormalParamPosition] as ParamPosition,

   5:        T.[Name] as ParamType

   6: from [Microsoft.Uml2].[Classes] C

   7:     inner join [Microsoft.Uml2].[Operations] O on (O.[Class] = C.[ID])

   8:         inner join [Microsoft.Uml2].[Parameters] Params on (Params.[Operation] = O.[Id])

   9:             inner join [Microsoft.Uml2].[Types] T on (T.[Id] = Params.[Type])

  10: where C.[Name] = 'individual' and C.[Folder] = [Repository.Item].[PathsFolder] ('MyModels/FourPlusOne')

Querying for Class Data – Better Together?

While the queries above are serviceable, they don’t quite mimic the same conceptual experience as working with a UML authoring tool. To that end, I started thinking about the shape of the data if I queried both class attributes and class operations in a single query. I won’t lie, I find this idea intriguing based on the fact that I’m an unrepentant Object-Oriented bigot. While I respect the power and mathematical beauty of the relational paradigm, I’m just more comfortable in OO land. In particular, I often visualize OO designs in my mind as UML (yes, I know that I’m sad and need to get a life ;-). As such, I was wondering how ugly it would be to bend SQL Server to my OO will.

NOTE – I’ve no doubt that many of the ideas, and code, in my blogging on querying the UML Domain will offend my T-SQL/Relational/SQL Server betters. However, IMHO addressing those of us with minds crippled by OO might find dealing with suboptimal T-SQL an excellent way of deriving value from the UML Domain. Let the flame mail begin :-).

In kicking around these ideas at a high level with Anthony Bloesch (BTW, don’t hold Anthony accountable for the content of these blog posts, he is an aforementioned SQL Server better of mine), it seemed like going the route of T-SQL unions was a superior approach to using Multiple Active Result Sets (MARS). The use of unions will allow me to get all of the UML class data in a single call and will also return it as a single result set. The downside will be a large collection of columns with many NULL values scattered throughout the result set.

Accepting the potential ugliness factor of using a T-SQL union, my first requirement in the new combined query is to add the placeholder columns needed for the class operations to the class attributes query. The following T-SQL illustrates this handiwork:

   1: select C.[Id] as ClassId, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        P.[Id] as PropertyId, P.[Name] as PropertyName, P.[Visibility] as PropertyVisibility, 

   3:        T.[Id] as PropertyTypeId, T.[Name] as PropertyTypeName,

   4:        null as OperationId, null as OperationName, null as OperationVisibility, null as OperationPosition,

   5:        null as ParameterID, null as ParamName, null as ParamDirection, null as ParamPosition,

   6:        null as ParamTypeName

   7: from [Microsoft.Uml2].[Classes] C

   8:     inner join [Microsoft.Uml2].[Properties] P on (C.[Id] = P.[Class])

   9:     inner join [Microsoft.Uml2].[Types] T on (T.[Id] = P.[Type])

  10: where C.[Name] = N'individual' and C.[Folder] = [Repository.Item].[PathsFolder] (N'MyModels/FourPlusOne')

Running the above T-SQL produces the following result set:

Modifying the class operations query

in the same way gives the following T-SQL and result set:

   1: select C.[Id] as ClassId, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        NULL as PropertyId, NULL as PropertyName, NULL as PropertyVisibility, NULL as PropertyTypeId, 

   3:        NULL as PropertyTypeName,

   4:        O.[Id] as OperationId, O.[Name] as OperationName, O.[Visibility] as OperationVisibility, 

   5:        O.[ClassPosition] as OperationPosition,

   6:        Params.[Id] as ParameterID, Params.[Name] as ParamName, Params.[Direction] as ParamDirection,

   7:        Params.[OwnerFormalParamPosition] as ParamPosition,

   8:        T.[Name] as ParamTypeName

   9: from [Microsoft.Uml2].[Classes] C

  10:     inner join [Microsoft.Uml2].[Operations] O on (O.[Class] = C.[ID])

  11:         inner join [Microsoft.Uml2].[Parameters] Params on (Params.[Operation] = O.[Id])

  12:             inner join [Microsoft.Uml2].[Types] T on (T.[Id] = Params.[Type])

  13: where C.[Name] = N'individual' and C.[Folder] = [Repository.Item].[PathsFolder] (N'MyModels/FourPlusOne')

Note in the above T-SQL I made some minor changes to the alias names to standardize the result sets across queries. Simple enough, now I just sandwich the T-SQL union keyword between the above two queries to get all the data back in a single call. To make things a little more usable, I’ll add a column named “RowType” to provide some metadata denoting whether a result set row is a class property or class operation (got this idea from my Dev team – Thx to Steve and Thomas). Here’s the T-SQL and result set:

   1: select C.[Id] as ClassId, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        NULL as PropertyId, NULL as PropertyName, NULL as PropertyVisibility, NULL as PropertyTypeId, 

   3:        NULL as PropertyTypeName,

   4:        O.[Id] as OperationId, O.[Name] as OperationName, O.[Visibility] as OperationVisibility, 

   5:        O.[ClassPosition] as OperationPosition,

   6:        Params.[Id] as ParameterID, Params.[Name] as ParamName, Params.[Direction] as ParamDirection,

   7:        Params.[OwnerFormalParamPosition] as ParamPosition,

   8:        T.[Name] as ParamTypeName

   9: from [Microsoft.Uml2].[Classes] C

  10:     inner join [Microsoft.Uml2].[Operations] O on (O.[Class] = C.[ID])

  11:         inner join [Microsoft.Uml2].[Parameters] Params on (Params.[Operation] = O.[Id])

  12:             inner join [Microsoft.Uml2].[Types] T on (T.[Id] = Params.[Type])

  13: where C.[Name] = N'individual' and C.[Folder] = [Repository.Item].[PathsFolder] (N'MyModels/FourPlusOne')

OK, the above result set is a tad on the ugly side, but I’m still intrigued by the possibilities of getting all the data for a class (from the perspective of a UML diagram canvas, that is) in a single call. I’m thinking this is worthy of one more post’s worth of exploration.

Next Time

Next time I’m going to explore using the above union query is even more interesting if it is converted to a SQL Server table-valued user-defined function (UDF). As always, any feedback from the community would be greatly appreciated.

Thanx for reading!

Refresher

As a refresher from last time, the following UML class represents the running example for the queries against the UML domain:

 Here’s the T-SQL from part 1:

   1: select C.[Id] as ClassName, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        P.[Id] as PropertyId, P.[Name] as PropertyName, P.[Visibility], 

   3:        T.[Id] as TypeId, T.[Name] as TypeName

   4: from [Microsoft.Uml2].[Classes] C

   5:     inner join [Microsoft.Uml2].[Properties] P on (C.[Id] = P.[Class])

   6:     inner join [Microsoft.Uml2].[Types] T on (T.[Id] = P.[Type])

   7: where C.[Name] = 'individual' and C.[Folder] = [Repository.Item].[PathsFolder] ('MyModels/FourPlusOne')

As I mentioned in the last post, I’m purposefully giving up some efficiency in my queries with the goal of returning the data for a UML class that mimics the UML diagram above. The snippet above illustrates this concept by returning some redundant data with each class attribute.

Querying for Operations

As one would expect, the UML Superstructure specifies that a class owns a collection of UML operations. Therefore, to get data relating to the GetFirstName(), SetFirstName(), or GetLastName() operations, I need to access the Microsoft.Uml2.Operations view. With the following T-SQL I can start to get back the data I need regarding the Individual class’ operations:

   1: select C.[Id] as ClassName, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        O.[Id] as OperationId, O.[Name] as OperationName, O.[Visibility], O.[ClassPosition]

   3: from [Microsoft.Uml2].[Classes] C

   4:     inner join [Microsoft.Uml2].[Operations] O on (O.[Class] = C.[ID])

   5: where C.[Name] = 'individual' and C.[Folder] = [Repository.Item].[PathsFolder] ('MyModels/FourPlusOne')

As the snippet above shows, I added some aliases to assist with readability. Executing the query above in Microsoft SQL Server Management Studio (SSMS) gives the following results:

Not bad, the results above illustrate the list of Operations on the Individual class. In case you were curious, the ClassPosition column denotes the order of the operations within the class. Now I just need to get the params for the operations.

Adding Parameters

Getting the parameters for an operation is a straightforward join between the Microsoft.Uml2.Operations and Microsoft.Uml2.Parameters views. The following T-SQL snippet illustrates:

   1: select C.[Id] as ClassName, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        O.[Id] as OperationId, O.[Name] as OperationName, O.[Visibility], O.[ClassPosition],

   3:        Params.[Id] as ParameterID, Params.[Name] as ParamName, Params.[Direction] as ParamDirection,

   4:        Params.[OwnerFormalParamPosition] as ParamPosition

   5: from [Microsoft.Uml2].[Classes] C

   6:     inner join [Microsoft.Uml2].[Operations] O on (O.[Class] = C.[ID])

   7:         inner join [Microsoft.Uml2].[Parameters] Params on (Params.[Operation] = O.[Id])

   8: where C.[Name] = 'individual' and C.[Folder] = [Repository.Item].[PathsFolder] ('MyModels/FourPlusOne')

The above query produces the following result set. Similar to the ClassPosition column, the ParamPosition column below denotes the position of the parameter within the operation:

Sweet, if I add one last piece of data – the parameter type – then the returned data for operations on the class will be complete. One more quick join and I’ll be good to go. Here’s the updated T-SQL:

   1: select C.[Id] as ClassName, C.[Folder] as FolderId, C.[ElementKind] as ClassKind, C.[Name] as ClassName,

   2:        O.[Id] as OperationId, O.[Name] as OperationName, O.[Visibility], O.[ClassPosition],

   3:        Params.[Id] as ParameterID, Params.[Name] as ParamName, Params.[Direction] as ParamDirection,

   4:        Params.[OwnerFormalParamPosition] as ParamPosition,

   5:        T.[Name] as ParamType

   6: from [Microsoft.Uml2].[Classes] C

   7:     inner join [Microsoft.Uml2].[Operations] O on (O.[Class] = C.[ID])

   8:         inner join [Microsoft.Uml2].[Parameters] Params on (Params.[Operation] = O.[Id])

   9:             inner join [Microsoft.Uml2].[Types] T on (T.[Id] = Params.[Type])

  10: where C.[Name] = 'individual' and C.[Folder] = [Repository.Item].[PathsFolder] ('MyModels/FourPlusOne')

And the complete Operations result set:

Right, the above result set conceptually maps to the data that is typically displayed for a class’ operations on a diagramming canvas.

Next Time

I’ve now got two queries that, taken together, represent the complete picture of a UML class – complete from the perspective of UML diagramming canvas, that is. However, I think it might be interesting to combine the two queries and play around with the idea of what a combined query would look like.

As the Program Manager for the UML Domain, I’d be highly interested in any feedback (good, bad, or indifferent) from the community about making the UML domain more usable. Do the two queries I’ve built so far seem interesting? Useful? Could you see them being used in SQL Server Reporting Services (SSRS) reports? If not, what queries would be useful?

Until next time, thanx for reading!