diagram type to display ERD

[Remo]

Has anyone ever thought about adding a way to define tables and relations to get a nice ERD? Even in times of NoSQL I often have to put ERDs in my documents.

[knsv]

:+1:

[Remo]

I had a quick look at how to create new types for mermaid. Don't have an jison experience, will have to dig into that. But before we go there, about the syntax. A quick search showed me two graphviz examples:

• http://stackoverflow.com/questions/22673352/colorize-table-name-in-graphviz-entity-relationship-diagram
• https://fsteeg.wordpress.com/2006/11/17/uml-class-diagrams-with-graphviz/

That syntax is okay, but I feel like it could be simplified since we wouldn't need that much flexibility. Something like that maybe:

table
   my_table_1
      id: int
      name: string
      date_created: date
   my_table_2
      id: int
      table_1_id: int
      name: string
      language: string
   my_table1:id > my_table_2:table_1_id

Or maybe specify the relations right in the table:

table
   my_table_1
      id: int
      name: string
      date_created: date
   my_table_2
      id: int
      table_1_id: int [my_table_1:id]
      name: string
      language: string

[knsv]

Sounds great!

I will will put this issue as assigned.

I like the syntax. Both syntaxes actually but after some pondering I would go with option 2. Reasoning is that it is easier to see the relation in context. With option 1 you need to do more scaning of the definition.

Actually in the synax both versions could be legal. Just send me a message if you want either to tag-team this, or pointers for working with jison and rendering.

[jhirbour]

👍

[mcdoyaji]

+1

[afraxas]

:+1:

[Remo]

I feel like I'm the wrong person for this task, not working in the field or parsing at all, but gave it a try. Currently try to parse this:

table
   my_table_1
      id: int
      name: string
      date_created: date

but end up with an error in the last line:

Expecting 'EOF', got '1'

Will be off for a while but it's still not the todo list, just give me a year or two..

/* description: Parses end executes mathematical expressions. */

/* lexical grammar */
%lex
%%

\s+                   return 'SPACE'
"table"               return 'TABLE'
":"                   return 'COLON'
\n                    return 'NEWLINE'
<<EOF>>               return 'EOF'
[a-zA-Z()_0-9]+       return 'IDENTIFIER'
.                     return 'INVALID'

/lex

/* operator associations and precedence */

%left '^'

%start expressions

%% /* language grammar */

expressions
    : tableConfig tables EOF
    ;

tableConfig
    : TABLE newlines 
        {$$ = $2;}
    ;

tables
    : IDENTIFIER newlines statements
    ;

statements
    :  statement newlines statements
        {$$=$1;}
    | statement EOF
        {$$=$1;}
    | statement newlines EOF
        {$$=$1;}
    ;

statement
    : IDENTIFIER COLON SPACE IDENTIFIER
    ;

newlines
    : NEWLINE newlines
    | SPACE newlines
    | NEWLINE
    | SPACE
    ;

[knsv]

Hi! Good to hear that you are working at this!

From what I can see you have EOF twice. The error message from jison was perhaps not very telling... :)

So if you for instance were to remove the EOF at the expressions statement as in below I think the parsing would work:

expressions
    : tableConfig tables
    ;

Perhaps cleaner to remove the if in statements section. Either would work.

[andruby]

I like the syntax used in the ERD tool: https://github.com/BurntSushi/erd

# Entities
[player]
  *player_id
  full_name
  team_id

[team]
  *team_id
  city
  name

[game]
  *game_id
  home_team_id
  away_team_id

# Relationships
player      *--1 team
game        *--1 team {label: "home"}
game        *--1 team {label: "away"}

[vijosoco]

Very interested to know if this work is still in progress. Possibly as an "experimental" option in mermaid sometime soon?

[megawubs]

What's the status of this?

[Remo]

I'm afraid, but I'm not working on this at the moment. I got distracted by other projects. While I still like the idea, I currently don't have the time to continue.

[megawubs]

Too bad, I like the supposed syntax way better than hacking an ERD like schema together with plantuml...

[andruby]

@megawubs if you want to use that syntax today, you can with @BurntSushi's awesome https://github.com/BurntSushi/erd tool. It can output pdf, png or dot for further processing.

[megawubs]

I did take a look at that, but it's too much hassle to set it up right now.

[psychemedia]

I note that class diagrams are now in experimental release. Chunks of the codebase for that may be reusable as a basis for ERDs, perhaps with different arrowheads as style options (eg crows foot)?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[IOrlandoni]

Given how long ago this issue's activity died out, I'm closing it. This allows us to maintain a fresh list of issues the community is interested in.

[theoretick]

I'd still be very much interested in this issue if you wouldn't mind keeping it open!

Class diagrams are useful but missing some key features of ERDs; such as the crow's feet mentioned by @psychemedia

[IOrlandoni]

Reopening manually (since our staleness rules are being re-vamped) but it might fall into inactivity and be closed again, eventually.

[Ahmed-Ayman]

any plans for this?

[tonytonyjan]

Today you can use class diagrams to draw an ERD with the latest version of mermaid.

[alcaprar]

Today you can use class diagrams to draw an ERD with the latest version of mermaid.

Hi @tonytonyjan , yes class diagram can be used but many ERD features are missing. It would be amazing to have at least different visibility for primary key, not null, unique.

[spopida]

Hi - I'm new here. I've been playing around recently with ERDs and I'd like to have a go at this in mermaid. My idea is slightly different from reverse engineering an ERD from a physical schema (a set of tables), although I can see the value in that. I've always used ER diagramming as a modelling tool, before I have a schema, so I propose to simply declare the basic entities and relationships and render a diagram. For example, the following would render a diagram with 2 entities and a one-to-many relationship:

erDiagram PERSON !-?< CAR : owns, is owned by

This reads as follows: a PERSON owns zero or more CARs; a CAR is owned by one and only one PERSON. Other types of relationship would be indicated like this:

A !-!< B means A has one or more Bs and B has one and only one A A ?-!< B means A has one or more Bs and B has zero or one A `A !-! B means A has one and only one B and B has one and only one A

...and so on. Basically, the exclamation mark implies that the role of the entity next to it is mandatory, and a question mark implies that the role of the entity next to it is optional. And of course the less than sign implies that there can me more than one of the entity next to it - it's meant to represent a crow's foot.

The above syntax is reversible, so A !-?< B is exactly the same as B >?-! A.

In terms of rendering I am leaning towards Barker's notation (aka Barker-Ellis notation) described extensively here, but in the long run the notation could be configurable, and in the short run, I'd start with just the basics which would be enough for a decent MVP.

I'd appreciate any thoughts on this by experienced contributors. I'd like to create a branch off develop if that's OK?

[knsv]

Loose thoughts:

Great that someone is willing to take on this issue. The syntax first looked quite daunting and complex, but after reading through it I see that it the ideas and rules behind it are sound and not complex at all. 👍 Though, maybe that initial impression could deter potential users... or maybe its short expressive notation will be one its best features.

Try modeling something real with the syntax and evaluate it.

Once the syntax is out there, it is there to stay. We cant expect end-users go through their authored diagrams and change it so think it though properly.

Also let me know if you need help or pointers moving forward.

[spopida]

Thanks - sound advice. I'll get something working on a branch and we can play around with a few choices around syntax. Totally get that it's an important thing to get right and will be hard to change.

[IOrlandoni]

@spopida I might be late to the party but... any chance that we could actually use PlantUMLs syntax instead of inventing our own? https://plantuml.com/es/ie-diagram