diff --git a/cypress/integration/rendering/erDiagram.spec.js b/cypress/integration/rendering/erDiagram.spec.js index 063727024..057b36dc1 100644 --- a/cypress/integration/rendering/erDiagram.spec.js +++ b/cypress/integration/rendering/erDiagram.spec.js @@ -255,4 +255,22 @@ describe('Entity Relationship Diagram', () => { ); cy.get('svg'); }); + + it('should render entities with aliases', () => { + renderGraph( + ` + erDiagram + T1 one or zero to one or more T2 : test + T2 one or many optionally to zero or one T3 : test + T3 zero or more to zero or many T4 : test + T4 many(0) to many(1) T5 : test + T5 many optionally to one T6 : test + T6 only one optionally to only one T1 : test + T4 0+ to 1+ T6 : test + T1 1 to 1 T3 : test + `, + { logLevel: 1 } + ); + cy.get('svg'); + }); }); diff --git a/docs/entityRelationshipDiagram.md b/docs/entityRelationshipDiagram.md index 78d058e78..97a0a1da3 100644 --- a/docs/entityRelationshipDiagram.md +++ b/docs/entityRelationshipDiagram.md @@ -110,10 +110,34 @@ Cardinality is a property that describes how many elements of another entity can | `}o` | `o{` | Zero or more (no upper limit) | | `}\|` | `\|{` | One or more (no upper limit) | +**Aliases** + +| Value (left) | Value (right) | Alias for | +| :----------: | :-----------: | ------------ | +| one or zero | one or zero | Zero or one | +| zero or one | zero or one | Zero or one | +| one or more | one or more | One or more | +| one or many | one or many | One or more | +| many(1) | many(1) | One or more | +| 1+ | 1+ | One or more | +| zero or more | zero or more | Zero or more | +| zero or many | zero or many | Zero or more | +| many(0) | many(1) | Zero or more | +| 0+ | 0+ | Zero or more | +| only one | only one | Exactly one | +| 1 | 1 | Exactly one | + ### Identification Relationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question can not have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : "driver"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line: +**Aliases** + +| Value | Alias for | +| :-----------: | :---------------: | +| to | _identifying_ | +| optionally to | _non-identifying_ | + ```mermaid-example erDiagram CAR ||--o{ NAMED-DRIVER : allows @@ -218,6 +242,7 @@ erDiagram string lastName int age } + MANUFACTURER only one to zero or more CAR ``` ```mermaid @@ -236,6 +261,7 @@ erDiagram string lastName int age } + MANUFACTURER only one to zero or more CAR ``` ### Other Things diff --git a/packages/mermaid/src/diagrams/er/parser/erDiagram.jison b/packages/mermaid/src/diagrams/er/parser/erDiagram.jison index 6294599b5..f0411fd72 100644 --- a/packages/mermaid/src/diagrams/er/parser/erDiagram.jison +++ b/packages/mermaid/src/diagrams/er/parser/erDiagram.jison @@ -36,15 +36,32 @@ accDescr\s*"{"\s* { this.begin("acc_descr_multili [\n]+ /* nothing */ "}" { this.popState(); return 'BLOCK_STOP'; } . return yytext[0]; + +"one or zero" return 'ZERO_OR_ONE'; +"one or more" return 'ONE_OR_MORE'; +"one or many" return 'ONE_OR_MORE'; +"1+" return 'ONE_OR_MORE'; \|o return 'ZERO_OR_ONE'; +"zero or one" return 'ZERO_OR_ONE'; +"zero or more" return 'ZERO_OR_MORE'; +"zero or many" return 'ZERO_OR_MORE'; +"0+" return 'ZERO_OR_MORE'; \}o return 'ZERO_OR_MORE'; +"many(0)" return 'ZERO_OR_MORE'; +"many(1)" return 'ONE_OR_MORE'; +"many" return 'ZERO_OR_MORE'; \}\| return 'ONE_OR_MORE'; +"one" return 'ONLY_ONE'; +"only one" return 'ONLY_ONE'; +"1" return 'ONLY_ONE'; \|\| return 'ONLY_ONE'; o\| return 'ZERO_OR_ONE'; o\{ return 'ZERO_OR_MORE'; \|\{ return 'ONE_OR_MORE'; \.\. return 'NON_IDENTIFYING'; \-\- return 'IDENTIFYING'; +"to" return 'IDENTIFYING'; +"optionally to" return 'NON_IDENTIFYING'; \.\- return 'NON_IDENTIFYING'; \-\. return 'NON_IDENTIFYING'; [A-Za-z][A-Za-z0-9\-_]* return 'ALPHANUM'; diff --git a/packages/mermaid/src/diagrams/er/parser/erDiagram.spec.js b/packages/mermaid/src/diagrams/er/parser/erDiagram.spec.js index 1d891ffea..eb738fe4b 100644 --- a/packages/mermaid/src/diagrams/er/parser/erDiagram.spec.js +++ b/packages/mermaid/src/diagrams/er/parser/erDiagram.spec.js @@ -532,18 +532,100 @@ describe('when parsing ER diagram it...', function () { expect(rels[0].relSpec.cardB).toBe(erDb.Cardinality.ONE_OR_MORE); }); + it('should handle zero-or-one-to-zero-or-more relationships (aliases "one or zero" and "zero or many")', function () { + erDiagram.parser.parse('erDiagram\nA one or zero to many B : has'); + const rels = erDb.getRelationships(); + + expect(Object.keys(erDb.getEntities()).length).toBe(2); + expect(rels.length).toBe(1); + expect(rels[0].relSpec.cardA).toBe(erDb.Cardinality.ZERO_OR_MORE); + expect(rels[0].relSpec.cardB).toBe(erDb.Cardinality.ZERO_OR_ONE); + }); + + it('should handle one-or-more-to-zero-or-one relationships (aliases "one or many" and "zero or one")', function () { + erDiagram.parser.parse('erDiagram\nA one or many optionally to zero or one B : has'); + const rels = erDb.getRelationships(); + + expect(Object.keys(erDb.getEntities()).length).toBe(2); + expect(rels.length).toBe(1); + expect(rels[0].relSpec.cardA).toBe(erDb.Cardinality.ZERO_OR_ONE); + expect(rels[0].relSpec.cardB).toBe(erDb.Cardinality.ONE_OR_MORE); + }); + + it('should handle zero-or-more-to-zero-or-more relationships (aliases "zero or more" and "zero or many")', function () { + erDiagram.parser.parse('erDiagram\nA zero or more to zero or many B : has'); + const rels = erDb.getRelationships(); + + expect(Object.keys(erDb.getEntities()).length).toBe(2); + expect(rels.length).toBe(1); + expect(rels[0].relSpec.cardA).toBe(erDb.Cardinality.ZERO_OR_MORE); + expect(rels[0].relSpec.cardB).toBe(erDb.Cardinality.ZERO_OR_MORE); + }); + + it('should handle zero-or-more-to-one-or-more relationships (aliases "many(0)" and "many(1)")', function () { + erDiagram.parser.parse('erDiagram\nA many(0) to many(1) B : has'); + const rels = erDb.getRelationships(); + + expect(Object.keys(erDb.getEntities()).length).toBe(2); + expect(rels.length).toBe(1); + expect(rels[0].relSpec.cardA).toBe(erDb.Cardinality.ONE_OR_MORE); + expect(rels[0].relSpec.cardB).toBe(erDb.Cardinality.ZERO_OR_MORE); + }); + + it('should handle zero-or-more-to-only-one relationships (aliases "many(0)" and "many(1)")', function () { + erDiagram.parser.parse('erDiagram\nA many optionally to one B : has'); + const rels = erDb.getRelationships(); + + expect(Object.keys(erDb.getEntities()).length).toBe(2); + expect(rels.length).toBe(1); + expect(rels[0].relSpec.cardA).toBe(erDb.Cardinality.ONLY_ONE); + expect(rels[0].relSpec.cardB).toBe(erDb.Cardinality.ZERO_OR_MORE); + }); + + it('should handle only-one-to-only-one relationships (aliases "only one" and "1+")', function () { + erDiagram.parser.parse('erDiagram\nA only one optionally to 1+ B : has'); + const rels = erDb.getRelationships(); + + expect(Object.keys(erDb.getEntities()).length).toBe(2); + expect(rels.length).toBe(1); + expect(rels[0].relSpec.cardA).toBe(erDb.Cardinality.ONE_OR_MORE); + expect(rels[0].relSpec.cardB).toBe(erDb.Cardinality.ONLY_ONE); + }); + + it('should handle zero-or-more-to-only-one relationships (aliases "0+" and "1")', function () { + erDiagram.parser.parse('erDiagram\nA 0+ optionally to 1 B : has'); + const rels = erDb.getRelationships(); + + expect(Object.keys(erDb.getEntities()).length).toBe(2); + expect(rels.length).toBe(1); + expect(rels[0].relSpec.cardA).toBe(erDb.Cardinality.ONLY_ONE); + expect(rels[0].relSpec.cardB).toBe(erDb.Cardinality.ZERO_OR_MORE); + }); + it('should represent identifying relationships properly', function () { erDiagram.parser.parse('erDiagram\nHOUSE ||--|{ ROOM : contains'); const rels = erDb.getRelationships(); expect(rels[0].relSpec.relType).toBe(erDb.Identification.IDENTIFYING); }); + it('should represent identifying relationships properly (alias "to")', function () { + erDiagram.parser.parse('erDiagram\nHOUSE one to one ROOM : contains'); + const rels = erDb.getRelationships(); + expect(rels[0].relSpec.relType).toBe(erDb.Identification.IDENTIFYING); + }); + it('should represent non-identifying relationships properly', function () { erDiagram.parser.parse('erDiagram\n PERSON ||..o{ POSSESSION : owns'); const rels = erDb.getRelationships(); expect(rels[0].relSpec.relType).toBe(erDb.Identification.NON_IDENTIFYING); }); + it('should represent non-identifying relationships properly (alias "optionally to")', function () { + erDiagram.parser.parse('erDiagram\n PERSON many optionally to many POSSESSION : owns'); + const rels = erDb.getRelationships(); + expect(rels[0].relSpec.relType).toBe(erDb.Identification.NON_IDENTIFYING); + }); + it('should not accept a syntax error', function () { const doc = 'erDiagram\nA xxx B : has'; expect(() => { diff --git a/packages/mermaid/src/docs/entityRelationshipDiagram.md b/packages/mermaid/src/docs/entityRelationshipDiagram.md index 341c9147c..e52b0df4c 100644 --- a/packages/mermaid/src/docs/entityRelationshipDiagram.md +++ b/packages/mermaid/src/docs/entityRelationshipDiagram.md @@ -85,10 +85,34 @@ Cardinality is a property that describes how many elements of another entity can | `}o` | `o{` | Zero or more (no upper limit) | | `}\|` | `\|{` | One or more (no upper limit) | +**Aliases** + +| Value (left) | Value (right) | Alias for | +| :----------: | :-----------: | ------------ | +| one or zero | one or zero | Zero or one | +| zero or one | zero or one | Zero or one | +| one or more | one or more | One or more | +| one or many | one or many | One or more | +| many(1) | many(1) | One or more | +| 1+ | 1+ | One or more | +| zero or more | zero or more | Zero or more | +| zero or many | zero or many | Zero or more | +| many(0) | many(1) | Zero or more | +| 0+ | 0+ | Zero or more | +| only one | only one | Exactly one | +| 1 | 1 | Exactly one | + ### Identification Relationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question can not have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : "driver"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line: +**Aliases** + +| Value | Alias for | +| :-----------: | :---------------: | +| to | _identifying_ | +| optionally to | _non-identifying_ | + ```mmd erDiagram CAR ||--o{ NAMED-DRIVER : allows @@ -155,6 +179,7 @@ erDiagram string lastName int age } + MANUFACTURER only one to zero or more CAR ``` ### Other Things