Closed aadrian closed 2 years ago
Already done. see https://github.com/plantuml/plantuml/pull/31.
This has been merged and is in the latest version. Note that the pull request example uses the '<' character for many, but the final version uses '{'.
This has been merged and is in the latest version
Thank you! This is great to know, but there's no versioning ( http://semver.org/ ) , no tags in sources and no dates in the changelogs either :( .
So it's not very clear what version, and from when does one have or needs to update to :( .
The primary development happens on SourceForge. Note that I am not a PlantUML developer - I just contributed some of the ER diagram code.
By latest version I meant the release that you can currently download on the PlantUML website (http://plantuml.com/download).
The primary development happens on SourceForge.
OK, so this is just a mirror than?
I just contributed some of the ER diagram code.
Thank you for that. It works great :) .
It's also being used here: https://github.com/nus/gitbucket-plantuml-plugin
for this https://github.com/gitbucket/gitbucket project.
ERD is practically the most useful type of diagram, since almost every developer is agreeing that such a diagram is needed when there are more than 5 DB Tables :) .
Cool. I also use GitBucket heavily. I didn't know that there was a GitBucket plugin for PlantUML - that could be very useful.
Yes this is basically a mirror. Arnaud does respond to pull request and issues, so some of us use GitHub to interact with the project. Hopefully we can lure him over from the dark side eventually. :)
PlantUML Version management is indeed far from perfect...
1) We have added dates on http://plantuml.com/changes
2) GitHub source is (for now...) just a mirror of SourceForce source. ( https://sourceforge.net/p/plantuml/code/HEAD/tree/ ) However, I cannot explain why we did not make any tags in GitHub... Sorry about that! In the future, we will also tag in GitHub (as we do in SourceForge)
3) About Version numbering, I think that we are going to change our numbers. Right now, we are using meaningless numbers (V8054, V8055, V8056...) What about using current year in future version numbers, so that next versions would be: V2017.01, V2017.02, V2017.03, V2017.04, (then next year) V2018.01, V2018.02 (We don't use Major/Minor release number, because basically we try to have full compatibility between PlantUML versions.)
At least, this would help people to know it their PlantUML version is recent or not. What do you think about it ?
I cannot explain why we did not make any tags in GitHub. Usually GitHub (Git) mirroring seems to work 100% only when the SF Subversion layout is a standard one.
What do you think about it ?
Sounds very good!
This is not related to ER Diagram support, but we've made a poll about new versioning scheme (see http://plantuml.com/versioning-scheme ). We think that our last proposal (like 2017.08) is not good enough.
@arnaudroques IMHO the proposed marjor.year.release
is even better, and very near to semver http://semver.org/ for a project that it's pushing releases often.
This is not related to ER Diagram support,
@arnaudroques Related to ER Diagram support however, maybe a help page and a link regarding this new ERD support on the official site would wake the interest for the tool for many new DB users? At the moment searching for plantuml +erd
on major search engines does not return a relevant page.
2 years later, the situation is the same
Which situation are you referring to?
Apart from the documentation, I would like to point there's some kind of "textual representation" for ER that could have been ported to PlantUML. I have found a comprehensive document about it.
I know I arrived late to the syntax discussion, but this syntax is related to the textual description of ER and, thus, closer to other documentation texts we can find or write (easier to reuse ;-)).
In short, it could have been like this:
@startuml
' __ could signal the Primary Key (just a suggestion)
entity Bus (__reg_no, make, size, deck, no_of_pass)
entity Route (__route_no, avg_pass)
entity Driver (__emp_no, name, cell)
entity Stage (__stage_no)
entity Town (__name)
Bus m..1 Route : is serviced by
Route 1..m Stage : comprises
Driver m..1 : is allocated to
Stage n..m Town : Passes-though
Route n..m Town : Passes-though
Which is more readable than the cryptic }|-||
(which is related to the drawn symbols, I know).
Also, the attributes can be written in a more classical way, less "java-ish", as show in the entities declarations. I.e., the "Bus" entity would be shown as
If attributes are listed and not hidden (hide attributes
, i.e.) they could be drawn following the ERD stadard: UseCase-like oval surrounding their entity, something like this:
And, just for completeness and drive the developers crazy, declare the relationships as diamonds if skinparam erdModel chen
, etc. :angel:
But, just a thought. Document the current implementation would be nice enough. O:)
[NOTE: I admit I do not usually set attributes in E-R diagrams...]
ER Diagram documentation is online! PlantUML Wiki Official Doc Site under Entity-Relationship Diagram
From/Since PR #31
Hi, I was really excited to see that PlantUML has support for ER diagrams. However, when I tried it out, I realized that my use case is not supported: I would like to specify which attributes my arrows start and end on. As implemented and documented here, PlantUML draws arrows between entities, but oftentimes when visualizing foreign key relationships between tables you want an arrow pointing from the foreign key of one table to the primary key of another.
Just some feedback. Keep up the good work, PlantUML is awesome!
@jimmyocto PlantUML has experimental support for this.
See: https://forum.plantuml.net/3636
I generally just use a <<FK>>
stereotype beside the attribute on the FK side to indicate which attribute represents the relationship.
Is any news about this?
I would really like to have this ER symbols:
Apart from the documentation, I would like to point there's some kind of "textual representation" for ER that could have been ported to PlantUML. I have found a comprehensive document about it.
I know I arrived late to the syntax discussion, but this syntax is related to the textual description of ER and, thus, closer to other documentation texts we can find or write (easier to reuse ;-)).
In short, it could have been like this:
@startuml ' __ could signal the Primary Key (just a suggestion) entity Bus (__reg_no, make, size, deck, no_of_pass) entity Route (__route_no, avg_pass) entity Driver (__emp_no, name, cell) entity Stage (__stage_no) entity Town (__name) Bus m..1 Route : is serviced by Route 1..m Stage : comprises Driver m..1 : is allocated to Stage n..m Town : Passes-though Route n..m Town : Passes-though
Which is more readable than the cryptic
}|-||
(which is related to the drawn symbols, I know). Also, the attributes can be written in a more classical way, less "java-ish", as show in the entities declarations. I.e., the "Bus" entity would be shown asIf attributes are listed and not hidden (
hide attributes
, i.e.) they could be drawn following the ERD stadard: UseCase-like oval surrounding their entity, something like this:And, just for completeness and drive the developers crazy, declare the relationships as diamonds if
skinparam erdModel chen
, etc. angelBut, just a thought. Document the current implementation would be nice enough. O:)
[NOTE: I admit I do not usually set attributes in E-R diagrams...]
Would it make sense to add the fields of a table in rows, where in columns the keys, the names and types are properly adjusted, so reading and organizing is much better:
PK, FK | name | type |
---|---|---|
PK | id | uid |
FK | fid | uid |
By that the arrows might contain the information regarding the FK keys, which are used to define the relation towards the next table, where the PKs have to match to those.
I tried to achieve the column design by some additional definitions:
skinparam defaultFontName "IBM Plex Mono"
' Show tables (PF) and index files (LF) in different colours
' 'P' and 'L' is related to DB2 i on IBM i (Physical, Logical Files)
!define PF (P,YellowGreen) Database Table
!define LF (L,DeepSkyBlue) Database Index
!define table(x) class x <<PF>>
!define index(x) class x <<LF>>
' show PK, FK as bold
!define primary_key(x) <b>PK\t x</b>
' reference is needed to generate SQL statement, not shown
!define foreign_key(x,reference) <b>FK\t </b>x
and then I used that extensively and was not able to easily fit into a table format, as it was nearly impossible to control the with of the columns efficiently:
table(SDSInfo){
{field} primary_key(InfoID InfoLNG) \t UID
..
{field} \t InfoName Char10
{field} \t InfoText Char80
{field} \t InfoHelp VarChar
{field} \t InfoMsg \t MSGID
}
The UID and the MSGID are not aligned. To me it's unpredictable, how the columns are formatted.
Just FYI, I think you-all can close this! ER Diagrams are now supported. 👍 Just looking to help clear your Issues queue here. Thank you for PlantUML and this feature.
Sorry, but the ER is a bit different from what plantuml implemented
The ER standard is usually like @mlopezgva pointed out (use cases like)
What PlantUML implements is a database diagram where there are PK, FK, and entities
Just FYI, I think you-all can close this! ER Diagrams are now supported. +1 Just looking to help clear your Issues queue here. Thank you for PlantUML and this feature.
Sorry, but the ER is a bit different from what plantuml implemented
@emiliogq That is not however what the feature request was for :) .
The requesst was for ERDs as https://www.lucidchart.com/pages/er-diagrams for the use cases described in that link - not for the old Chen relationship notation https://en.wikipedia.org/wiki/File:ERD_Representation.svg
PlantUML implemented very nicely the "Crow's Foot" relationship notation, and we are very thankful for that ( it is extemely useful in most projects that involve data modeling ) !
Sorry, but the ER is a bit different from what plantuml implemented
@emiliogq That is not however what the feature request was for :) .
The requesst was for ERDs as https://www.lucidchart.com/pages/er-diagrams for the use cases described in that link - not for the old Chen relationship notation https://en.wikipedia.org/wiki/File:ERD_Representation.svg
PlantUML implemented very nicely the "Crow's Foot" relationship notation, and we are very thankful for that ( it is extemely useful in most projects that involve data modeling ) !
Hahaha okay I got it, thank you for this remark and sorry for this mistake, I did not read the whole thread, I apologize.
PS: I'd say Chen diagram is not that old, at least, nowadays, it is taught at university :stuck_out_tongue_closed_eyes:
I'd say Chen diagram is not that old, at least, nowadays, it is taught at university
@emiliogq
If it's is still used in universities, than please open a new issue requesting expressly the "Chen Notation".
The symbols missing from a Chen Notation seem to be: "Weak", "Multi-valued" and "Relationship" (but this one seems to exists for activity diagrams).
Please add support for ER Diagrams! https://www.lucidchart.com/pages/er-diagrams
Thank you.