From 245e25f4b7393b5b1001ee38288934a7fddc77a1 Mon Sep 17 00:00:00 2001 From: Adrian Hall Date: Fri, 23 Oct 2020 10:00:17 +0100 Subject: [PATCH] Allow underscores in entity names, and entities with no relationships --- .../integration/rendering/erDiagram.spec.js | 17 ++++++++++++++ .../entityRelationshipDiagram.md | 22 ++++++++++--------- src/diagrams/er/parser/erDiagram.jison | 3 ++- src/diagrams/er/parser/erDiagram.spec.js | 19 ++++++++++++++++ 4 files changed, 50 insertions(+), 11 deletions(-) diff --git a/cypress/integration/rendering/erDiagram.spec.js b/cypress/integration/rendering/erDiagram.spec.js index a387bf254..c72798e4c 100644 --- a/cypress/integration/rendering/erDiagram.spec.js +++ b/cypress/integration/rendering/erDiagram.spec.js @@ -141,4 +141,21 @@ describe('Entity Relationship Diagram', () => { expect(svg).to.not.have.attr('style'); }); }); + + it('should render entities that have no relationships', () => { + renderGraph( + ` + erDiagram + DEAD_PARROT + HERMIT + RECLUSE + SOCIALITE }o--o{ SOCIALITE : "interacts with" + RECLUSE }o--o{ SOCIALITE : avoids + `, + { er: { useMaxWidth: false } } + ); + cy.get('svg'); + }); + + }); diff --git a/docs/diagrams-and-syntax-and-examples/entityRelationshipDiagram.md b/docs/diagrams-and-syntax-and-examples/entityRelationshipDiagram.md index 6e2bef467..cb52685de 100644 --- a/docs/diagrams-and-syntax-and-examples/entityRelationshipDiagram.md +++ b/docs/diagrams-and-syntax-and-examples/entityRelationshipDiagram.md @@ -6,7 +6,7 @@ sort: 7 > An entity–relationship model (or ER model) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types). Wikipedia. -Note that practitioners of ER modelling almost always refer to *entity types* simply as *entities*. For example the CUSTOMER entity type would be referred to simply as the CUSTOMER entity. This is so common it would be inadvisable to do anything else, but technically an entity is an abstract *instance* of an entity type, and this is what an ER diagram shows - abstract instances, and the relationships between them. This is why entities are always named using singular nouns. +Note that practitioners of ER modelling almost always refer to *entity types* simply as *entities*. For example the `CUSTOMER` entity *type* would be referred to simply as the `CUSTOMER` entity. This is so common it would be inadvisable to do anything else, but technically an entity is an abstract *instance* of an entity type, and this is what an ER diagram shows - abstract instances, and the relationships between them. This is why entities are always named using singular nouns. Mermaid can render ER diagrams @@ -30,23 +30,23 @@ Relationships between entities are represented by lines with end markers represe ## Status -ER diagrams are a new feature in Mermaid and are **experimental**. There are likely to be a few bugs and constraints, and enhancements will be made in due course. Currently you can only define entities and relationships, but not attributes. +ER diagrams are a relatively new feature in Mermaid, so there are likely to be a few bugs and constraints, and enhancements will be made in due course. Currently you can only define entities and relationships, but not attributes. Inclusion of attributes is now actively being worked on. ## Syntax ### Entities and Relationships -Mermaid syntax for ER diagrams is compatible with PlantUML, with an extension to label the relationship. Each statement consists of the following parts, all of which are mandatory: +Mermaid syntax for ER diagrams is compatible with PlantUML, with an extension to label the relationship. Each statement consists of the following parts: ```markdown - : + [ : ] ``` Where: -- `first-entity` is the name of an entity. Names must begin with an alphabetic character and may also contain digits and hyphens +- `first-entity` is the name of an entity. Names must begin with an alphabetic character and may also contain digits, hyphens, and underscores. - `relationship` describes the way that both entities inter-relate. See below. -- `second-entity` is the name of the other entity +- `second-entity` is the name of the other entity. - `relationship-label` describes the relationship from the perspective of the first entity. For example: @@ -57,6 +57,8 @@ For example: This statement can be read as *a property contains one or more rooms, and a room is part of one and only one property*. You can see that the label here is from the first entity's perspective: a property contains a room, but a room does not contain a property. When considered from the perspective of the second entity, the equivalent label is usually very easy to infer. (Some ER diagrams label relationships from both perspectives, but this is not supported here, and is usually superfluous). +Only the `first-entity` part of a statement is mandatory. This makes it possible to show an entity with no relationships, which can be useful during iterative construction of diagrams. If any other parts of a statement are specified, then all parts are mandatory. + ### Relationship Syntax The `relationship` part of each statement can be broken down into three sub-components: @@ -69,10 +71,10 @@ Cardinality is a property that describes how many elements of another entity can | Value (left) | Value (right) | Meaning | |:------------:|:-------------:|--------------------------------------------------------| -| `\|o` | `o\|` | Zero or one | -| `\|\|` | `\|\|` | Exactly one | -| `}o` | `o{` | Zero or more (no upper limit) | -| `}\|` | `\|{` | One or more (no upper limit) | +| `|o` | `o|` | Zero or one | +| `||` | `||` | Exactly one | +| `}o` | `o{` | Zero or more (no upper limit) | +| `}|` | `|{` | One or more (no upper limit) | ### Identification diff --git a/src/diagrams/er/parser/erDiagram.jison b/src/diagrams/er/parser/erDiagram.jison index c1041a1da..339e57c4b 100644 --- a/src/diagrams/er/parser/erDiagram.jison +++ b/src/diagrams/er/parser/erDiagram.jison @@ -27,7 +27,7 @@ o\{ return 'ZERO_OR_MORE'; \-\- return 'IDENTIFYING'; \.\- return 'NON_IDENTIFYING'; \-\. return 'NON_IDENTIFYING'; -[A-Za-z][A-Za-z0-9\-]* return 'ALPHANUM'; +[A-Za-z][A-Za-z0-9\-_]* return 'ALPHANUM'; . return yytext[0]; <> return 'EOF'; @@ -67,6 +67,7 @@ statement yy.addRelationship($1, $5, $3, $2); /*console.log($1 + $2 + $3 + ':' + $5);*/ } + | entityName { yy.addEntity($1); } ; entityName diff --git a/src/diagrams/er/parser/erDiagram.spec.js b/src/diagrams/er/parser/erDiagram.spec.js index 2dc49415e..afe236452 100644 --- a/src/diagrams/er/parser/erDiagram.spec.js +++ b/src/diagrams/er/parser/erDiagram.spec.js @@ -14,6 +14,25 @@ describe('when parsing ER diagram it...', function() { erDiagram.parser.yy.clear(); }); + it ('should allow stand-alone entities with no relationships', function() { + const line1 = 'ISLAND'; + const line2 = 'MAINLAND'; + erDiagram.parser.parse(`erDiagram\n${line1}\n${line2}`); + + expect(Object.keys(erDb.getEntities()).length).toBe(2); + expect (erDb.getRelationships().length).toBe(0); + }); + + it ('should allow hyphens and underscores in entity names', function() { + const line1 = 'DUCK-BILLED-PLATYPUS'; + const line2 = 'CHARACTER_SET'; + erDiagram.parser.parse(`erDiagram\n${line1}\n${line2}`); + + const entities = erDb.getEntities(); + expect (entities["DUCK-BILLED-PLATYPUS"]).toBe('DUCK-BILLED-PLATYPUS'); + expect (entities.CHARACTER_SET).toBe('CHARACTER_SET'); + }); + it('should associate two entities correctly', function() { erDiagram.parser.parse('erDiagram\nCAR ||--o{ DRIVER : "insured for"'); const entities = erDb.getEntities();