What would be the equivalent of ERD for a NoSQL database such as MongoDB?

[zack_syah]

in SQL we make ERD to explain the relationships between data in the database based ondata base objects which have a relation between.

as we all know that no join in MongoDB.

I must make the documentation for my application. In order my teachers to understand how database in mongoDB

What would be the equivalent of ERD for a NoSQL database such as MongoDB?

thanks b4

[Martin Wawrusch]

A UML class diagram perhaps? 

Take a look at  http://www.visual-paradigm.com/solution/freeumltool/?src=google&kw=UML&mt=b&net=g&plc=&gclid=CPGgwIqypqwCFcKDDgodazh-_w 

for a free (at least they say so) UML modelling tools

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-user/-/B9YRyoCpggoJ.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Sam Millman]

UML is a modeling language not a specific diagram and it actually includes ERD.

You can model a NoSQL DB much like a SQL db, even with the same tools.

Since an ERD does not actually show field level details (or at least not at that stage it shouldn't) it should be pretty bog standard to think of the different entities you can draw for your DB.

I have always found that both SQL and Mongo have relatively static application entities (tables/collections) while it is the schema for these entities that shifts.

So for example you would do a little normalisation for Mongo but not too much.

[Sam Millman]

Also a class diagram is application level where as you are trying to let your teachers understand the DB level so I would recommend sticking with ERD.

[Sam Millman]

Forwarding this to mongodb-user, noticed a few errors too so I have corrected them:

Column names are not valid ERD syntax due to the nature of an ERD. ERDs are designed to only detail relations between entities, at most you place the connecting field names at either end of the one-to-many relationships etc (but even that is taking UML standards a little far).

In UML 2 normalisation (normally 3NF, pre ERD) usually decides your initial columns and then ERD would decide the relationships between normalised tables while a DTD (pre normalisation) will decide the context and bounderies of the system. That is how a normal design process takes shape, of course UML is simply a guideline and is not designed to be followed to the letter at all times.

If you really wanna display you tables in a relational manner (like in ERD) with column names then there is another diagram much like a class diagram that allows you to do that (though I have actually forgotten its name now). To represent columns as you ask I would normally include: [name, phone, email]. For fields that are potentially 'n' I would just state an example line and then be done with it personally. I mean Mongo is schemaless which means normalisation of its entities are done via logical and speed constraints so your diagram wouldn't make much sense anyway.

Mapping the required rules and fields in the application layer via a class diagram would be much better than trying to map the DB side in this way.

On 1 February 2012 09:00, Sam Millman <sam.m...@gmail.com> wrote:

Column Name Are not valid ERD syntax due to the nature of an ERD. ERDs are designed to only relation entities to one another, at most you place the connecting field names at either end of the one-to-many relationships etc (but even that is taking UML standards a little far).


In UML 2 normalisation (normally 3NF, pre ERD) will normally decide your initial columns and then ERD would decide the relationships between normalised tables while a DTD (pre normalisation) will decide the context and bounderies of the system.

On 1 February 2012 08:55, shinn <shi...@gmail.com> wrote:

Hi Sam, I've read your reply that an ERD can be used for MongoDB.
However, let's says in my db I have

{ db.contacts.save( {name: 'Foo', phone: 12345}, {name: 'Bar', email:
'b...@foo.com'} ) }

so how will my ERD looks like? Is it with a `table` name contacts but
what about the 'column' ? Do I included all [name, phone, email] in
it?

Sorry but I am new to MongoDB. Thanks in advance!

On Nov 8 2011, 5:19 pm, Sam Millman <sam.mill...@gmail.com> wrote:
> Also a class diagram is application level where as you are trying to let
> your teachers understand the DB level so I would recommend sticking with
> ERD.
>

> On 8 November 2011 09:15, Sam Millman <sam.mill...@gmail.com> wrote:
>
>
>
>
>
>
>
> > UML is a modeling language not a specific diagram and it actually includes
> > ERD.
>
> > You can model a NoSQL DB much like a SQL db, even with the same tools.
>
> > Since an ERD does not actually show field level details (or at least not
> > at that stage it shouldn't) it should be pretty bog standard to think of
> > the different entities you can draw for your DB.
>
> > I have always found that both SQL and Mongo have relatively static
> > application entities (tables/collections) while it is the schema for these
> > entities that shifts.
>
> > So for example you would do a little normalisation for Mongo but not too
> > much.
>

> > On 8 November 2011 06:19, Martin Wawrusch <mar...@wawrusch.com> wrote:
>
> >> A UML class diagram perhaps?
>
> >> Take a look at

> >>http://www.visual-paradigm.com/solution/freeumltool/?src=google&kw=UM...

[shinn]

Thanks for clarifying, I'd use class diagram I think. Btw what is
DTD(pre normalisation)?
Does it mean Document Type Definition ?

On Feb 1, 5:13 pm, Sam Millman <sam.mill...@gmail.com> wrote:
> Forwarding this to mongodb-user, noticed a few errors too so I have
> corrected them:
>
> Column names are not valid ERD syntax due to the nature of an ERD. ERDs are
> designed to only detail relations between entities, at most you place the
> connecting field names at either end of the one-to-many relationships etc
> (but even that is taking UML standards a little far).
>
> In UML 2 normalisation (normally 3NF, pre ERD) usually decides your initial
> columns and then ERD would decide the relationships between normalised
> tables while a DTD (pre normalisation) will decide the context and
> bounderies of the system. That is how a normal design process takes shape,
> of course UML is simply a guideline and is not designed to be followed to
> the letter at all times.
>
> If you really wanna display you tables in a relational manner (like in ERD)
> with column names then there is another diagram much like a class diagram
> that allows you to do that (though I have actually forgotten its name now).
> To represent columns as you ask I would normally include: [name, phone,
> email]. For fields that are potentially 'n' I would just state an example
> line and then be done with it personally. I mean Mongo is schemaless which
> means normalisation of its entities are done via logical and speed
> constraints so your diagram wouldn't make much sense anyway.
>
> Mapping the required rules and fields in the application layer via a class
> diagram would be much better than trying to map the DB side in this way.
>

> On 1 February 2012 09:00, Sam Millman <sam.mill...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Column Name Are not valid ERD syntax due to the nature of an ERD. ERDs are
> > designed to only relation entities to one another, at most you place the
> > connecting field names at either end of the one-to-many relationships etc
> > (but even that is taking UML standards a little far).
>
> > In UML 2 normalisation (normally 3NF, pre ERD) will normally decide your
> > initial columns and then ERD would decide the relationships between
> > normalised tables while a DTD (pre normalisation) will decide the context
> > and bounderies of the system.
>

> > On 1 February 2012 08:55, shinn <shin...@gmail.com> wrote:
>
> >> Hi Sam, I've read your reply that an ERD can be used for MongoDB.
> >> However, let's says in my db I have
>
> >> { db.contacts.save( {name: 'Foo', phone: 12345}, {name: 'Bar', email:

> >> '...@foo.com'} ) }

[Sam Millman]

Nah sorry about saying DTD I am not doing very well on my mistakes today (tired as always). I was meant to say behaviour diagrams, three diagrams that are normally used to explain the systems bounderies in terms of behaviours and what not (useful when done before the application part of class diagram etc): http://en.wikipedia.org/wiki/Unified_Modeling_Language#Behavior_diagrams. The Use case diagram being the most popular of these (can very easily outline the requirements of your system so you can start doing the class diagram easily enough).