Private Preview - features may change without notice
GramSpec
Architecture Spec API Reference Pricing About
Start free

Make the model · 1

One report, from a conversation to a loaded star

The answer to “our data is a mess and we have no warehouse.” Two people, two conversations: one says what the business measures, the other shows where each word lives. The star schema, its load and the report come from those, the same afternoon.

Starmaker. One flow is the person who needs the report saying what they measure, and a star derived from their sentences. The other is the person who knows the database matching each word to a column, and the load copying those rows into a star schema that is saved as a graph and a board.GRAMSPECYOUR DATAWhoever needs thereportWhoever knows thedatabaseYour wordsone sentence at a timeYour starworked out by rule from thedrawingYour dataeach word matched to acolumn, with an assistantThe loaddimensions, facts, acalendar, then checksThe stara schema of its own on ourSQLThe star's graphand a board, read byPalmtree, Vision and ReasonThe language modelYour databaseread-only123123456 Starmaker. One flow is the person who needs the report saying what they measure, and a star derived from their sentences. The other is the person who knows the database matching each word to a column, and the load copying those rows into a star schema that is saved as a graph and a board.GRAMSPECYOUR DATAWhoeverneeds thereportWhoeverknows thedatabaseYour wordsone sentence at atimeYour starYour dataeach word matchedto a column, withan assistantThe loadThe stara schema of itsown on our SQLThe star'sgraphThe languagemodelYourdatabaseread-only123123456
Blue circles are what the business measures. Green squares are where it lives, and the load.

What you measure

  1. Whoever needs the report says what they measure. One sentence at a time, in their own words, never a column name. No database is connected yet.
  2. The model turns each sentence into the drawing. It runs the same modeler Grammar uses, inside Starmaker's own rules, and what comes back is the things, the facts between them and how many of each, as sentences the person can read back and correct.
  3. The star is worked out from the drawing by rule. Which thing is the event, which are its numbers and what it is counted by follow from what the sentences said about one and many, and from nothing else. No model is asked and no name is read. A thing nobody gave a count for stays open and says so.

Where it lives, and the load

  1. Whoever knows the database picks the connection. Its list of tables is read once, and only the words on the drawing are looked up in it.
  2. An assistant reads their database for those words, and they confirm. It searches the table list, reads values on their own connection, read-only, and proposes where each word lives. A table or column that is not there is refused by name, and nothing it proposes is used until that person ticks it.
  3. The plan for the star goes to the load. It is made on the page from the confirmed columns and checked on the server before a row is read.
  4. Rows are read from their database, straight into the star. Each dimension once, then each fact, then one calendar across them. Nothing is written to their database. One load of a project runs at a time, and it runs to its end even if the page is closed.
  5. The star lands in a schema of its own, and is checked. The grain and every link from a fact to a dimension are tested against the loaded rows. A check that fails is kept and shown, never fixed quietly.
  6. The star is saved as an ordinary model, with a board. The same things and sentences the words made, now bound to the star's tables, so Palmtree, Vision and Reason read it like any other model. A board is made from the words, and each load seals a version.

Where the copy lives. The rows a star needs are copied into a schema of that project's own on our SQL, because the star has to exist somewhere to be read. Their database is only ever read.