Imagine you have a simple customers table in your database that looks like so:

etc.

To model this in Embeddable you might create a file like so:

cubes:
  - name: customers
    title: My customers
    sql_table: public.customers

    dimensions:
      - name: id 
        sql: id
        type: number
        primary_key: true

      - name: email
				title: "Email address"
        sql: email
        type: string

      - name: country
				title: "Country of origin"
        sql: country
        type: string

      - name: signed_up_date
				title: "Signed up date"
        sql: signed_up_at
        type: time

    measures:
      - name: count
        type: count
        title: '# of customers'

A few things to notice:

• Data models in Embeddable are referred to as cubes. This is because we use the very popular and very powerful modeling library, Cube, for our modeling layer. This ensures that you have all the flexibility and power to describe your data models, the way you need to, no matter how complex your database schemas are. We strongly encourage you to check out their fantastic documentation.
• We’ve supplied both a name and a title for both the data model itself and the dimensions and measures. The name is required and must be a unique name (no spaces or funny characters) that Embeddable will use behind the scenes to save metadata against your data model (try not to change these later). Whereas title is optional, and is a human-readable name that will appear in our no-code builder UI (so change these whenever you like).
• We’ve defined a single measure called count. This will just allow us to count the rows of this table in Embeddable. Supported measure types include:
  • count
  • count_distinct
  • count_distinct_approx
  • sum
  • avg
  • min
  • max
• We’ve defined a dimension for every column in the database table. This is not necessary, but can be the case if your database tables are quite clean and tidy (lucky you!). Think of dimensions as the virtual columns that you would like to expose to the no-code builder. Examples of when you may choose not to expose a column as a dimension exactly as is include:

  • you have a first_name and a last_name column and you want to instead expose a full_name dimension. In that case you might instead define a dimension like so:

    - name: full_name
    	title: "Full name"
    	type: string
    	sql: CONCAT(first_name, ' ', last_name) # this SQL should be the dialect of your database
    

  • you store timestamps in unix time (seconds since 1 jan 1970) and need to convert them to a timestamp. Here you might define a dimension like so:

    - name: created_at
    	title: "Signed up at"
    	type: time
    	sql: TO_TIMESTAMP(created_at) # this SQL should be the dialect of your database
    

  • you need to apply some transformation from the raw data to a human-readable format, e.g:

    - name: price
    	title: "Price in dollars"
    	type: number
    	sql: price_in_cents / 100.0 # this SQL should be the dialect of your database
    

Next up:

Dimensions and Measures

Further reading

Cube data playground