Hi @WarwickFoster, thanks for posting in the Lucid Community! The lines in your Entity Relationship Diagram should automatically be drawn between foreign keys and primary keys. Can you confirm that the entities you dragged out have those relationships indicated within your data file?

The import CSV data above should replicate the issue. Is there anything to change to Line 3 to make it appears by default?

Hi @WarwickFoster, I appreciate your patience here! After some testing on my end, it appears that a FOREIGN KEY constraint can only point to one table and each table can only have one PRIMARY KEY constraint. In order to accomplish what you are describing, I believe TableB and TableC would need to contain Foreign Keys and would need to reference a Primary Key in TableA, rather than a Foreign Key.

That is a specific limitation of your tool and will limit your use in complex regular ERD modelling. 

It is a normal practice with Polymorphic fields that one property can reference more than one table. In a normal complex data model it is often the case that a Notes Table could have one property called OwningObject and that property references hundreds of other tables. Resulting in hundreds of lines when the whole model is on the page. (I can demonstrate this if there is a need)

I would often not be having the hundreds of these boxes on a model but when wanting to explicitly present this data I have to Fake it in the data models in Excel so that the diagrams present correctly. 

This means though that I have to continuously reprocess my data from DB to Excel to Lucid expanding out Polymorphic fields.

noteId
owningobjectid
owningobjectid-->TableB
owningobjectid-->TableC
text
type

postgresql;"TEST";"public";"TableA";"TableAId";"1";"UniqueId";;"PRIMARY KEY";"public";"";""
postgresql;"TEST";"public";"TableA";"ObjectId";"2";"Poly";;"FOREIGN KEY";"public";"";""
postgresql;"TEST";"public";"TableA";"ObjectId -> TableB";"2";"Lookup";;"FOREIGN KEY";"public";"TableB";"TableBId"
postgresql;"TEST";"public";"TableA";"ObjectId -> TableC";"2";"Lookup";;"FOREIGN KEY";"public";"TableC";"TableCId"
postgresql;"TEST";"public";"TableA";"Feild1";"3";"Choice";;"""";;;
postgresql;"TEST";"public";"TableB";"TableBId";"1";"UniqueId";;"PRIMARY KEY";"public";"";""
postgresql;"TEST";"public";"TableC";"TableCId";"1";"UniqueId";;"PRIMARY KEY";"public";"";""

 @WarwickFoster, thank you for following up with that additional information. Polymorphic fields sidestep a Database’s typical Foreign Key constraints, and our ERD tool is designed for traditional DBMS. The solution you’ve created, having multiple FK fields that each reference a different table, is the next best thing for you to use in Lucid to help you visualize all those possible relationships.

However, I would like to pass this feedback onto our Product team. I’ve converted this post to an idea so that it’s visible to others within the Product Feedback section of the community - from here, other users also can upvote it and add details of their own.

For more information on how Lucid manages feedback via this community, take a look at this post: