Data Modelling in Hummi

Table of contents:

The flexibility of datalog in a fluid UI. Hummi stores everything in a database. Hummi enables user modelling.

  • Build queries with UI
  • Express graphs
    • optional edges (a node may have no edges)
    • constraints on edges (exclude edges to nodes that are not in the node set)
    • bfs or dfs to find more nodes by edge when allowing inclusion of external nodes
  • Update results. Every value must be tied to an entity
  • Every column must have a name (for table view) especially optional many rels

Entities

A collection of attributes with associated values.

Like a row in a table in most databases, and like a map datastructure.

AttributeValue
person/emailtim@hummi.com
person/nameTim
person/hairred
person/likeschocolate, coffee, hummingbirds

Must have an id attribute nominated. The id is necessary to determine the entity type. In this case email is the id. Id can be auto generated or user supplied. All other attributes are optional unless user specified as required. Notice that attributes can have multiple values associated with them.

Schema

Attributes and types that describe how entities relate, and what values are allowable.

Similar to Datomic/Datascript but with some enforced conventions.

Attribute

Attributes are qualified keys with a namespace that matches the entity type, and a name that describes the value to associate with it.

Like a column name in most databases, or a key in a map datastructure.

Example: person/email

Entity type

A namespace. The schema maintains an index of entity type to the attributes that belong to that namespace. Like a table name.

Example: person

Attribute type

One of string, number, date, uuid, relation. May additionally be flagged as id, unique, one, many, or required.

Like a column type in most databases.

Example: string required

Unique Features

  • Good defaults and conventions
  • Data ownership
  • Data sharing (organizations)
  • Combining databases

Query

Queries as patterns that look like what you are searching for.

Typical query build:

  1. Choose an entity
  2. Choose related entities
  3. Add conditions
  4. Shape results But might want to do in any order.

Examples

What groups exist in my organization based on shared calendar events?

What’s the average meeting load on my team?

team – person – availability

Visualizing: For n <= 20, separate line for each for n > 20, bands? distributions? distribution over time (these are just quantile bands?)?

Who is spending too much time in meetings?

What meetings could be deleted?

How much time is available for my project? (Sans leave/holidays/meetings)