---
tags: Cantor, sql
---

# Cantor notebook use cases

## Case 1 - Development
- Who: One developer alone
- When: Implementing a model from a specification which means much coding and little collaboration
- Why: Feedback from Cantor on the work already done
1. Verify that new declarations got right. View of the subset of the model you’re currently working on so it doesn’t get drowned in everything else.
2. Explore the data to find likely attributes and relations to use. The names and content of existing data often let you make qualified guesses without specifications.
3. Switch between 1 and 2
- What:
1. View a subset of the model to focus on the test. E.g. a selection of attributes where the selection contains also the new declarations
2. Search for elements (and content), search for paths between datasets and attributes

## Case 2 - Collaboration
- Who: Developer together with domain experts (operation and source system)
- When: Joint effort explore, debug or to define how to specify a new part of the model
- Why: Everybody must have some kind of understanding of the model to contribute
- What:
1. Reduce the view to only the most essential so that everybody can understand.
2. The domain experts should, hopefully, understand more than the developer explains by looking at the Cantor interface

## Case 3 - Asynchronous Documentation
- Who: Developer to other developers and domain experts
- When: Developer should explain something but isn't doing it live
- Why: There's a need to create a pedagogical progression in the explanation
- What: The break down of the documentation use cases is made here: [Cantor Documenation Use Cases](https://hackmd.io/pJZ2ZJPjTnCqmTsHGHHDJQ)
1. Reduce the view to only the most essential so that everybody can understand.
2. The domain experts should, hopefully, understand more than the developer explains by looking at the Cantor interface

## Case 4 - Prototype Use cases
- Who: The cantor developer team
- When: When improving the front end
- Why: To get a quick way to test how to meet cantor user use cases with new Cantor front end feature
- What: Solve Cantor user use cases in notebooks. If you can solve a use case in a simple way in a notebook it’s probably a good feature to implement in the app.

## Case 5 - Links from other documents
- Who: Developers and domain experts
- When: When presenting solutions
- Why: When the presenter want to use another format for the presentation but needs to integrate with cantor.
- What: Links to Cantor graphs and datasets that can be inserted in other documents.

## Example of case 3 - Inline attributes and relations

When creating a dataset it is often possible to create many attributes in it in the same query. The condition to make this possible is that we can rewrite the element so that all attribute references start over one source relation.

Here is a, contrived, example:

We want to create the data set `"tofu sales"` together with the attribute `a`. The attribute `"tofu sales".a` uses the relation `customers` which cannot be created until after `"tofu sales"` is created. Without changes we cannot create `a` with less than running two SQL queries.


However, if we rewrite the model slightly it is possible to create both of them in this single query (if only the `only` function existed in sql):

select
	Row,
	"order_details<-customers".only(address) as a
from order_details as "order_details"
    left join products as "order_details<-products"
    	on "order_details<-products".product_id = "order_details".product_id
    left join categories as "order_details<-products<-categories"
    	on "order_details<-products<-categories".category_id = "order_details".order_id
    left join customers as "order_details<-customers"
    	on "order_details<-customers".customer_id = "order_details".customer_id
    left join from customer as "order_details<-customer"
	on "order_details<-customer”.customer_id = "order_details<-customers”.customer_id
where 
	"order_details<-products”.product_name == 'Tofu'

The changes we made are:
1. Create the relation `order_details.customers`
2. We can substitute the `customers` relation in the attribute `"tofu sales".a` with `order_details.customers`
- Before: `customers.only(address)`
- After: `order_details.customers.only(address)`


Cantor schema queries for the two graphs:

1. Before inline

Attribute "tofu sales" "a"  >+> allDependent

2. After inline

Attribute "tofu sales" "a_inline"  >+> allDependent