Kamaelia based (Extended) Entity Relationship Modelling Tool
Posted by Michael on 25 Nov 2007 at 01:52
This weekend's hack - a tool to make my life easier - a tool to make creation, modelling and playing with extended entity relationship diagrams simpler (Of the kind found in Elmasri & Navathe). The tool is currently sitting in my /Sketches/MPS area named somewhat imaginatively ERTopologyTool.py and I think it's really quite funky. I'm using it to make it easier to communicate ideas I've got on the participate project (which is taking most of my dayjob time at the moment), and it can take a textual description of the schema that looks like this:
entity missionagent
entity person(missionagent)
entity team(missionagent)
entity missionitem:
simpleattributes visible
entity activemission
relation participatesin(activemission,missionagent)
relation creates(missionagent,missionitem)
It then internally maps this first to an AST and then that's transformed into commands for a modified version of the TopologyVisualiser which look like this:
ADD NODE missionagent missionagent auto entity
ADD NODE person person auto entity
ADD NODE ISA1 isa auto isa
ADD NODE team team auto entity
ADD NODE missionitem missionitem auto entity
ADD NODE visible visible auto attribute
ADD NODE activemission activemission auto entity
ADD NODE participatesin participatesin auto relation
ADD NODE creates creates auto relation
ADD LINK ISA1 missionagent
ADD LINK person ISA1
ADD LINK team ISA1
ADD LINK missionitem visible
ADD LINK activemission participatesin
ADD LINK missionagent participatesin
ADD LINK missionagent creates
ADD LINK missionitem creates
And then finally that's rendered, and the final rendered version looks like this:
... and I personally think that's really kinda sweet. I wrote the code to compile a little language into the visualiser's little language, largely because this will simplify adding the attributes to all the entities in the main version of the model I'm working with. (the above is a kinda fragment). The vaguely amusing thing about this is that this inherits the autolayout goodness of earlier work, results in a program with relatively high levels of natural concurrency and took the best part of a day to write, but not all day. That's amusing because such things of auto-layout, high levels of concurrency in a simple user application, and EER diagram modelling tools have been the sort of thing that used to be the level of a third year project at one time... Whereas here, it's an afternoon/day's hack.
So, what's next?
So, what's next?
- An interesting possibility I have here, which I may or may not do next is add in automated table generation - this sort of diagram contains sufficient information normally to allow direct creation of a database schema in boyce-codd normal form, though I'm more likely to work on adding in layering. (which is more directly useful for API building and UI abstractions)
- Other things I need to add in: cardinality constraints, key indicators, composite & repeated attributes, attributes of relations, weak entities, "must" constraints for relations, disjunction, conjunction and union subtyping (at the moment "isa" just implies disjunction).
- Packaging up as a separate/standalone package/tool ala Kamaelia Grey.
Comments
Tried out on someone else #
Nothing like trying out modelling someone else's model to test your system. OK, so I downloaded the dia file from this page on the Manchester Computer Science website to see what their models look like today. Pretty much as they used to, but it looked simpler to me than I remember. Anyhow, I did the obvious of mapping their model to a textual description:
entity Artist:This worked pretty well, but we have some issues:
simpleattributes artisticname genre
entity Manager:
simpleattributes ID name1 telephone
entity ContractInfo:
simpleattributes contractID data_from data_to duration1
entity MasterTrack:
simpleattributes trackID working_title duration2
entity SoundEngineer:
simpleattributes sound_eng_ID name2
entity FinishedTrack:
simpleattributes version final_duration released_title
entity Album:
simpleattributes album_ID title
relation ManagedBy(Artist,Manager)
relation HasContract(Artist,ContractInfo)
relation RecordedBy(MasterTrack,Artist)
relation EditedBy(SoundEngineer,MasterTrack)
relation OriginatesFrom(FinishedTrack,MasterTrack)
relation GroupedOn(FinishedTrack,Album)
# simpleattributes sequence
relation CreatedBy(Album,Artist)
- No weak entities
- No calculated attribute
- No repeated attributes
- No attributes on relations
- No way of indicating an attribute is a key
- No way of indicating an attribute is a partial key
- You'll note we have some odd attribute names: duration1, duration2, name1, name2 - this is due to the naming of attributes being global rather than scoped.
So, what does the resulting diagram look like?
