GitHub/mermaid
1
0
Fork 0
mirror of https://github.com/mermaid-js/mermaid.git synced 2025-01-28 07:03:17 +08:00
Code Issues Projects Releases Wiki Activity

Add classes to ERD elements

Browse Source 
It's a little hard to style the current ERDs. This aims to make things
easier by associating a distinct class with each type of element within
the diagram.

I've added a common `er` class across the elements so that those that
bring their own `themeCSS` can target styles at this diagram type. This
hasn't really been done elsewhere so I'm open to suggestions; an
alternative may be to add classes to a top-level element so that we can
do e.g. `svg.mermaid.er .entityBox`.
This commit is contained in:
Ryan Ling 2020-07-11 20:34:57 +10:00
parent c390e9e877
commit 20e56d7dfa
No known key found for this signature in database
GPG Key ID: F03D4D72670827BB
2 changed files with 46 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
docs/entityRelationshipDiagram.md
View File

@ -5,17 +5,19 @@
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
```
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
```
```mermaid
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
```
```mermaid
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
```
Entity names are often capitalised, although there is no accepted standard on this, and it is not required in Mermaid.
@ -31,9 +33,11 @@ ER diagrams are a new feature in Mermaid and are **experimental**. There are li
### 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
<first-entity> <relationship> <second-entity> : <relationship-label>
```
Where:
- `first-entity` is the name of an entity. Names must begin with an alphabetic character and may also contain digits and hyphens
@ -43,7 +47,7 @@ Where:
For example:
```
```mermaid
PROPERTY ||--|{ ROOM : contains
```
@ -51,9 +55,9 @@ This statement can be read as *a property contains one or more rooms, and a room
### Relationship Syntax
The `relationship` part of each statement can be broken down into three sub-components:
The `relationship` part of each statement can be broken down into three sub-components:
- the cardinality of the first entity with respect to the second,
- the cardinality of the first entity with respect to the second,
- whether the relationship confers identity on a 'child' entity
- the cardinality of the second entity with respect to the first
@ -68,13 +72,37 @@ Cardinality is a property that describes how many elements of another entity can
### 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:
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:
```
```mermaid
CAR ||--o{ NAMED-DRIVER : allows
PERSON ||--o{ NAMED-DRIVER : is
```
### Other Things
- If you want the relationship label to be more than one word, you must use double quotes around the phrase
- If you don't want a label at all on a relationship, you must use an empty double-quoted string
## Styling
### Config options
For simple color customization:
| Name | Used as |
| :------- | :------------------------------------------------------ |
| `fill` | Background color of an entity |
| `stroke` | Border color of an entity, line color of a relationship |
### Classes used
The following CSS class selectors are available for richer styling:
| Selector | Description |
| :--------------------------- | :---------------------------------------------------- |
| `.er.entityBox` | The box representing an entity |
| `.er.entityLabel` | The label for an entity |
| `.er.relationshipLabel` | The label for a relationship |
| `.er.relationshipLabelBox` | The box surrounding a relationship label |
| `.er.relationshipLine` | The line representing a relationship between entities |

5
src/diagrams/er/erRenderer.js
View File

@ -43,6 +43,7 @@ const drawEntities = function(svgNode, entities, graph) {
const textId = 'entity-' + id;
const textNode = groupNode
.append('text')
.attr('class', 'er entityLabel')
.attr('id', textId)
.attr('x', 0)
.attr('y', 0)
@ -65,6 +66,7 @@ const drawEntities = function(svgNode, entities, graph) {
// Draw the rectangle - insert it before the text so that the text is not obscured
const rectNode = groupNode
.insert('rect', '#' + textId)
.attr('class', 'er entityBox')
.attr('fill', conf.fill)
.attr('fill-opacity', '100%')
.attr('stroke', conf.stroke)
@ -148,6 +150,7 @@ const drawRelationshipFromLayout = function(svg, rel, g, insert) {
// Insert the line at the right place
const svgPath = svg
.insert('path', '#' + insert)
.attr('class', 'er relationshipLine')
.attr('d', lineFunction(edge.points))
.attr('stroke', conf.stroke)
.attr('fill', 'none');
@ -224,6 +227,7 @@ const drawRelationshipFromLayout = function(svg, rel, g, insert) {
const labelNode = svg
.append('text')
.attr('class', 'er relationshipLabel')
.attr('id', labelId)
.attr('x', labelPoint.x)
.attr('y', labelPoint.y)
@ -241,6 +245,7 @@ const drawRelationshipFromLayout = function(svg, rel, g, insert) {
// Insert the opaque rectangle before the text label
svg
.insert('rect', '#' + labelId)
.attr('class', 'er relationshipLabelBox')
.attr('x', labelPoint.x - labelBBox.width / 2)
.attr('y', labelPoint.y - labelBBox.height / 2)
.attr('width', labelBBox.width)