representing MongoDB document in UML
2,875 views
Skip to first unread message
aliane abdelouahab
Sep 26, 2012, 8:28:33 AM9/26/12
to mongodb-user
hi
it's a dumb question, but how do i make it? am making a project where
i'll use UML, but the problem that the project i've seen are using
tables with joins. do i use the conventional MCD to represente it?
my schema is:
user = {information about him}
user={"personnel":{
"email":email,
"pseudo":pseudo,
"password":password,
"tel":tel,
"statut":statut,
"nom":nom,
"prenom":prenom,
"daten":daten,
"sexe":sexe},
"avatar":{
"orientation":orientation,
"avctype":avctype,
"avatar":avatar_id},
"adresse":{
"wilaya":wilaya,
"commune":commune,
"coord":coord,
"site":site
}
}
and because mongodb is dynamic typed, fusioned with python, that the
client will have the product only if he uploads or buys one, so i'll
use $push.
product_up = {information about the product uploaded}
"produit_up"={
"spec":{
"id":id,
"nombre":nombre,
"namep":namep,
"prix":prix,
"description":description,
"tags":tags,
"date":date,
"abus":0,
"vendu":False
},
"avatar":
{
"photo":avatar_id,
"avctype":avctype,
"orientation":orientation,
}
}
product_buy = {information about the product that he added to cart}
so as you can see, it's a "denormalized" model.
it's a dumb question, but how do i make it? am making a project where
i'll use UML, but the problem that the project i've seen are using
tables with joins. do i use the conventional MCD to represente it?
my schema is:
user = {information about him}
user={"personnel":{
"email":email,
"pseudo":pseudo,
"password":password,
"tel":tel,
"statut":statut,
"nom":nom,
"prenom":prenom,
"daten":daten,
"sexe":sexe},
"avatar":{
"orientation":orientation,
"avctype":avctype,
"avatar":avatar_id},
"adresse":{
"wilaya":wilaya,
"commune":commune,
"coord":coord,
"site":site
}
}
and because mongodb is dynamic typed, fusioned with python, that the
client will have the product only if he uploads or buys one, so i'll
use $push.
product_up = {information about the product uploaded}
"produit_up"={
"spec":{
"id":id,
"nombre":nombre,
"namep":namep,
"prix":prix,
"description":description,
"tags":tags,
"date":date,
"abus":0,
"vendu":False
},
"avatar":
{
"photo":avatar_id,
"avctype":avctype,
"orientation":orientation,
}
}
product_buy = {information about the product that he added to cart}
so as you can see, it's a "denormalized" model.
Sam Millman
Sep 26, 2012, 11:19:59 AM9/26/12
to mongod...@googlegroups.com
Hmm it is probably time to create a standard diagram modeling method for designing MongoDB databases.
However as you have noticed first hand there is no real standard and nor is there a previously defined standard.
UML though can work on denormalised models but you have to add the application joins as well. For example your ERD might show every subdocument set as a separate entity and a embedded relation between it and its parent object.
What part of the UML cycle are you designed exactly?
However as you have noticed first hand there is no real standard and nor is there a previously defined standard.
UML though can work on denormalised models but you have to add the application joins as well. For example your ERD might show every subdocument set as a separate entity and a embedded relation between it and its parent object.
What part of the UML cycle are you designed exactly?
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb
Sam Millman
Sep 26, 2012, 11:32:27 AM9/26/12
to mongod...@googlegroups.com
Infact I am going to put an RFC out there for embedded relation types in a ERD stating that embedded relation type is: 1:$
aliane abdelouahab
Sep 26, 2012, 11:55:23 AM9/26/12
to mongodb-user
because there is a lot of things to take in account:
dynamic: so there is no forced schema, even if a developper will guess
the futur...
there is no joins: nested documents, so it will be king of XML
databases (only heard about)
because am doing 4 diagrams: sequence, use case, object, and the one
concerting database, but this one, i've found from the examples i
wanted to inspirate that it is a RELATIONAL, and this NoSQL (NO
RELATIONAL), and it's a thesis that i must give in 10 days, so i know
that the judges will make 10 hours asking me about this :p
dynamic: so there is no forced schema, even if a developper will guess
the futur...
there is no joins: nested documents, so it will be king of XML
databases (only heard about)
because am doing 4 diagrams: sequence, use case, object, and the one
concerting database, but this one, i've found from the examples i
wanted to inspirate that it is a RELATIONAL, and this NoSQL (NO
RELATIONAL), and it's a thesis that i must give in 10 days, so i know
that the judges will make 10 hours asking me about this :p
Sam Millman
Sep 26, 2012, 2:57:48 PM9/26/12
to mongod...@googlegroups.com
Oh you will have to annotate. I mean MongoDB cannot be written with what most teachers know of UML. So yes you will need to add some serious amounts of writing work to stress to them what Mongo is and why you have done what you have done.
Though if they dunno what NoSQL is and why your planning work lacks a lot of the normal stuff relational work does then they should prolly read wikipedia and a few other sites. So if you just give a nice small white paper about NoSQL I reckon it would suffice to tell them your work flow.
But as I said if you describe the diagram, cos the first post you provided was a bit hard to understand (I must be honest), you are having problems with and where the problem is in the diagram I am sure we can help you find a syntax that will work.
Though if they dunno what NoSQL is and why your planning work lacks a lot of the normal stuff relational work does then they should prolly read wikipedia and a few other sites. So if you just give a nice small white paper about NoSQL I reckon it would suffice to tell them your work flow.
But as I said if you describe the diagram, cos the first post you provided was a bit hard to understand (I must be honest), you are having problems with and where the problem is in the diagram I am sure we can help you find a syntax that will work.
aliane abdelouahab
Sep 26, 2012, 5:30:58 PM9/26/12
to mongodb-user
am sorry in the first post, i wrote the terme using a french one, here
is Algeria (africa) we learn using french language, i've got serious
problems trying to translating from english to french due the lack of
noSql papers in french, so the MCD refers to Model Conceptuel de
Données which in english means Entity Relational Model,
about NoSql, i've a made about 20 pages explaining it with simplest
word and exposing the problem of using it instead of Sql and i hope
they'll understand this, but you know the problem with teachers: THEY
LOVE PARETO'S LAW; so they'll try to use 20% of the problem to block
80% of the project :p
so this is why i said, maybe i can build a good ERM and then when they
ask me, i'll sing my NoSql song :D
so do i represent it only like JSON documents? i've seen (dont
remember) a BigTable example using bizarre notations! and then, what
about one-to-one and one-to-many, since it's a document, and
everything is nested, then no need of this?
is Algeria (africa) we learn using french language, i've got serious
problems trying to translating from english to french due the lack of
noSql papers in french, so the MCD refers to Model Conceptuel de
Données which in english means Entity Relational Model,
about NoSql, i've a made about 20 pages explaining it with simplest
word and exposing the problem of using it instead of Sql and i hope
they'll understand this, but you know the problem with teachers: THEY
LOVE PARETO'S LAW; so they'll try to use 20% of the problem to block
80% of the project :p
so this is why i said, maybe i can build a good ERM and then when they
ask me, i'll sing my NoSql song :D
so do i represent it only like JSON documents? i've seen (dont
remember) a BigTable example using bizarre notations! and then, what
about one-to-one and one-to-many, since it's a document, and
everything is nested, then no need of this?
Sam Millman
Sep 27, 2012, 6:10:20 AM9/27/12
to mongod...@googlegroups.com
It all depends on what you class as a ERM. To me and ERM is just another view of ERD:
http://www.databasedesign.co.uk/bookdatabasesafirstcourse/chap3/chap3.htm
en.wikipedia.org/wiki/Entity–relationship_model
So I am not sure how you mean by JSON document, this was probably my confusion in your first post.
So what are you trying to draw? If you give a full example it might help because you don't normally define the fields of a table/collection until the normalisation step which occurs after the UML diagrams.
Though it is strange that you learn in French, I would have expected Arabic if anything :)
http://www.databasedesign.co.uk/bookdatabasesafirstcourse/chap3/chap3.htm
en.wikipedia.org/wiki/Entity–relationship_model
So I am not sure how you mean by JSON document, this was probably my confusion in your first post.
So what are you trying to draw? If you give a full example it might help because you don't normally define the fields of a table/collection until the normalisation step which occurs after the UML diagrams.
Though it is strange that you learn in French, I would have expected Arabic if anything :)
aliane abdelouahab
Sep 27, 2012, 6:48:40 AM9/27/12
to mongodb-user
no, in algeria the first language is arabic, but all what is related
to technology is learned in french (the are exception where they learn
in english, but it is in one or two universities..).
about the application, it is doing a real simple stuff:
a client has no product information, so when he buys something (add to
cart since there is no epaymement here, only add the information to
its account), then the new product will be added, and it's not the
reference to this product that will be written to its data, but the
whole product information, so it will be a "denormalization"?
same thing happens with product uploaded (sold), so there is no
foreign keys, except for GridFS pictures, a document have the max of
16 MB so i must use GridFS to hold pictures and store only their _id
(i think this is the only 'join' that exists)
On 27 sep, 11:10, Sam Millman <sam.mill...@gmail.com> wrote:
> It all depends on what you class as a ERM. To me and ERM is just another
> view of ERD:
>
> http://www.databasedesign.co.uk/bookdatabasesafirstcourse/chap3/chap3...
>
> en.wikipedia.org/wiki/Entity–relationship_model<http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model>
to technology is learned in french (the are exception where they learn
in english, but it is in one or two universities..).
about the application, it is doing a real simple stuff:
a client has no product information, so when he buys something (add to
cart since there is no epaymement here, only add the information to
its account), then the new product will be added, and it's not the
reference to this product that will be written to its data, but the
whole product information, so it will be a "denormalization"?
same thing happens with product uploaded (sold), so there is no
foreign keys, except for GridFS pictures, a document have the max of
16 MB so i must use GridFS to hold pictures and store only their _id
(i think this is the only 'join' that exists)
On 27 sep, 11:10, Sam Millman <sam.mill...@gmail.com> wrote:
> It all depends on what you class as a ERM. To me and ERM is just another
> view of ERD:
>
>
> en.wikipedia.org/wiki/Entity–relationship_model<http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model>
>
> So I am not sure how you mean by JSON document, this was probably my
> confusion in your first post.
>
> So what are you trying to draw? If you give a full example it might help
> because you don't normally define the fields of a table/collection until
> the normalisation step which occurs after the UML diagrams.
>
> Though it is strange that you learn in French, I would have expected Arabic
> if anything :)
>
> So I am not sure how you mean by JSON document, this was probably my
> confusion in your first post.
>
> So what are you trying to draw? If you give a full example it might help
> because you don't normally define the fields of a table/collection until
> the normalisation step which occurs after the UML diagrams.
>
> Though it is strange that you learn in French, I would have expected Arabic
> if anything :)
>
Sam Millman
Sep 27, 2012, 6:56:14 AM9/27/12
to mongod...@googlegroups.com
I would add that embedding is a internal JOIN within the document itself.
So say you have one collection of Blog and in each row you have a looping array of Post. That would be a one to many relationship between the entity Blog and the entity Post and I would personally show those two as separate entities since they are which means they would be separate boxes on the ERM/ERD.
Hope this helps to clear up the embedding problem a little
So say you have one collection of Blog and in each row you have a looping array of Post. That would be a one to many relationship between the entity Blog and the entity Post and I would personally show those two as separate entities since they are which means they would be separate boxes on the ERM/ERD.
Hope this helps to clear up the embedding problem a little
aliane abdelouahab
Sep 27, 2012, 7:00:46 AM9/27/12
to mongodb-user
but if there is a "fake" joins, then i represent the FK in the posts
as the PK of the blog?
On 27 sep, 11:56, Sam Millman <sam.mill...@gmail.com> wrote:
> I would add that embedding is a internal JOIN within the document itself.
>
> So say you have one collection of Blog and in each row you have a looping
> array of Post. That would be a one to many relationship between the entity
> Blog and the entity Post and I would personally show those two as separate
> entities since they are which means they would be separate boxes on the
> ERM/ERD.
>
> Hope this helps to clear up the embedding problem a little
>
as the PK of the blog?
On 27 sep, 11:56, Sam Millman <sam.mill...@gmail.com> wrote:
> I would add that embedding is a internal JOIN within the document itself.
>
> So say you have one collection of Blog and in each row you have a looping
> array of Post. That would be a one to many relationship between the entity
> Blog and the entity Post and I would personally show those two as separate
> entities since they are which means they would be separate boxes on the
> ERM/ERD.
>
> Hope this helps to clear up the embedding problem a little
>
Sam Millman
Sep 27, 2012, 7:04:29 AM9/27/12
to mongod...@googlegroups.com
I don't think you need to worry about the PKs and FKs on a ERM or ERD only the process between them and their JOIN type i.e.:
- One to One (1:1)
- One to Many (1:M)
- Many to Many (which theoritically should never exist) (M:M)
And then you state that the normalisation (where the fields and PK and FK are built up) does not exist due to the nature of MongoDB.
I would, for embedded (fake) JOINs add another JOIN type though, and I would clearly explain it:
- Many Embbeded (1:$)
This is the annotation you would use on the relational line between blog and post in the example I gave you.
- One to One (1:1)
- One to Many (1:M)
- Many to Many (which theoritically should never exist) (M:M)
And then you state that the normalisation (where the fields and PK and FK are built up) does not exist due to the nature of MongoDB.
I would, for embedded (fake) JOINs add another JOIN type though, and I would clearly explain it:
- Many Embbeded (1:$)
This is the annotation you would use on the relational line between blog and post in the example I gave you.
Sam Millman
Sep 27, 2012, 7:05:21 AM9/27/12
to mongod...@googlegroups.com
"I don't think you need to worry about the PKs and FKs on a ERM or ERD only the process between them and their JOIN type i.e.:"
Was meant to say:I don't think you need to worry about the PKs and FKs on a ERM or ERD only the entities within your database and the processes between them and their JOIN type i.e.:
Sam Millman
Sep 27, 2012, 7:09:45 AM9/27/12
to mongod...@googlegroups.com
I have a brilliant idea. Replace the normalisation step with a class diagram: http://en.wikipedia.org/wiki/Class_diagram
This way your diagrams will show the DBs relations and fields in a denormalised and NoSQL manner, hopefully.
This way your diagrams will show the DBs relations and fields in a denormalised and NoSQL manner, hopefully.
aliane abdelouahab
Sep 27, 2012, 7:14:11 AM9/27/12
to mongodb-user
but the Class Diagram is also there, it's the first time i make an UML
representation, but from the old thesis where i inspirate, they did
both: Class Diagram and ERM! or will i integrate database information
in the class diagram?
On 27 sep, 12:10, Sam Millman <sam.mill...@gmail.com> wrote:
> I have a brilliant idea. Replace the normalisation step with a class
> diagram:http://en.wikipedia.org/wiki/Class_diagram
>
> This way your diagrams will show the DBs relations and fields in a
> denormalised and NoSQL manner, hopefully.
>
representation, but from the old thesis where i inspirate, they did
both: Class Diagram and ERM! or will i integrate database information
in the class diagram?
On 27 sep, 12:10, Sam Millman <sam.mill...@gmail.com> wrote:
> I have a brilliant idea. Replace the normalisation step with a class
> diagram:http://en.wikipedia.org/wiki/Class_diagram
>
> This way your diagrams will show the DBs relations and fields in a
> denormalised and NoSQL manner, hopefully.
>
> On 27 September 2012 12:05, Sam Millman <sam.mill...@gmail.com> wrote:
>
>
>
>
>
>
>
> > "I don't think you need to worry about the PKs and FKs on a ERM or ERD
> > only the process between them and their JOIN type i.e.:"
>
> > Was meant to say:
>
> > I don't think you need to worry about the PKs and FKs on a ERM or ERD only
> > the entities within your database and the processes between them and their
> > JOIN type i.e.:
>
>
>
>
>
>
>
>
> > "I don't think you need to worry about the PKs and FKs on a ERM or ERD
> > only the process between them and their JOIN type i.e.:"
>
> > Was meant to say:
>
> > I don't think you need to worry about the PKs and FKs on a ERM or ERD only
> > the entities within your database and the processes between them and their
> > JOIN type i.e.:
>
> > On 27 September 2012 12:04, Sam Millman <sam.mill...@gmail.com> wrote:
>
> >> I don't think you need to worry about the PKs and FKs on a ERM or ERD
> >> only the process between them and their JOIN type i.e.:
>
> >> - One to One (1:1)
> >> - One to Many (1:M)
> >> - Many to Many (which theoritically should never exist) (M:M)
>
> >> And then you state that the normalisation (where the fields and PK and FK
> >> are built up) does not exist due to the nature of MongoDB.
>
> >> I would, for embedded (fake) JOINs add another JOIN type though, and I
> >> would clearly explain it:
>
> >> - Many Embbeded (1:$)
>
> >> This is the annotation you would use on the relational line between blog
> >> and post in the example I gave you.
>
>
> >> I don't think you need to worry about the PKs and FKs on a ERM or ERD
> >> only the process between them and their JOIN type i.e.:
>
> >> - One to One (1:1)
> >> - One to Many (1:M)
> >> - Many to Many (which theoritically should never exist) (M:M)
>
> >> And then you state that the normalisation (where the fields and PK and FK
> >> are built up) does not exist due to the nature of MongoDB.
>
> >> I would, for embedded (fake) JOINs add another JOIN type though, and I
> >> would clearly explain it:
>
> >> - Many Embbeded (1:$)
>
> >> This is the annotation you would use on the relational line between blog
> >> and post in the example I gave you.
>
Sam Millman
Sep 27, 2012, 7:17:01 AM9/27/12
to mongod...@googlegroups.com
I would say put your DB fields and PKs and FKs into the class diagram.
You cannot really represent them on the ERM due to the schemaless nature of Mongo.
You cannot really represent them on the ERM due to the schemaless nature of Mongo.
Sam Millman
Sep 27, 2012, 7:21:06 AM9/27/12
to mongod...@googlegroups.com
I suppose taking the example from wikipedia, you could miss out FKs altogether if you were to put the stuff onto the ERM.
Since if you were to explain the JOIN type and that there is NO FK then there would be no need to show one for the JOIN right? Which should fix everything.
But this method might be confusing, it might be better to go with putting it all into the class diragram and only show the top level entities on the ERM.
Since if you were to explain the JOIN type and that there is NO FK then there would be no need to show one for the JOIN right? Which should fix everything.
But this method might be confusing, it might be better to go with putting it all into the class diragram and only show the top level entities on the ERM.
aliane abdelouahab
Sep 27, 2012, 7:25:50 AM9/27/12
to mongodb-user
it's what will make ;)
thank you for following me till the solution :)
by the way: in MongoView, i've tested it yersterday,and it give me
"View Table", always the SQL terms following us :p
On 27 sep, 12:21, Sam Millman <sam.mill...@gmail.com> wrote:
> I suppose taking the example from wikipedia, you could miss out FKs
> altogether if you were to put the stuff onto the ERM.
>
> Since if you were to explain the JOIN type and that there is NO FK then
> there would be no need to show one for the JOIN right? Which should fix
> everything.
>
> But this method might be confusing, it might be better to go with putting
> it all into the class diragram and only show the top level entities on the
> ERM.
>
thank you for following me till the solution :)
by the way: in MongoView, i've tested it yersterday,and it give me
"View Table", always the SQL terms following us :p
On 27 sep, 12:21, Sam Millman <sam.mill...@gmail.com> wrote:
> I suppose taking the example from wikipedia, you could miss out FKs
> altogether if you were to put the stuff onto the ERM.
>
> Since if you were to explain the JOIN type and that there is NO FK then
> there would be no need to show one for the JOIN right? Which should fix
> everything.
>
> But this method might be confusing, it might be better to go with putting
> it all into the class diragram and only show the top level entities on the
> ERM.
>
> On 27 September 2012 12:17, Sam Millman <sam.mill...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I would say put your DB fields and PKs and FKs into the class diagram.
>
> > You cannot really represent them on the ERM due to the schemaless nature
> > of Mongo.
>
>
>
>
>
>
>
>
> > I would say put your DB fields and PKs and FKs into the class diagram.
>
> > You cannot really represent them on the ERM due to the schemaless nature
> > of Mongo.
>
Sam Millman
Sep 27, 2012, 7:29:39 AM9/27/12
to mongod...@googlegroups.com
Heh indeed :) even using a completely different tech doesn't save you from the SQL terminology :)
Np glad to have helped, that's what we are here for :)
Np glad to have helped, that's what we are here for :)
aliane abdelouahab
Sep 27, 2012, 7:33:04 AM9/27/12
to mongodb-user
thank you again.
شكرا لك this one is using arabic (Chokran laka), it's the "official"
algerian language, but Algeria is not all arabs, there is Amazighs, so
with my mother tongue i say : Thanmirth (sadly CSS2.1 will not accept
using the font-face to write it with a font that accepts unicode
4.1 ;) )
On 27 sep, 12:29, Sam Millman <sam.mill...@gmail.com> wrote:
> Heh indeed :) even using a completely different tech doesn't save you from
> the SQL terminology :)
>
> Np glad to have helped, that's what we are here for :)
>
> ...
>
> plus de détails »
شكرا لك this one is using arabic (Chokran laka), it's the "official"
algerian language, but Algeria is not all arabs, there is Amazighs, so
with my mother tongue i say : Thanmirth (sadly CSS2.1 will not accept
using the font-face to write it with a font that accepts unicode
4.1 ;) )
On 27 sep, 12:29, Sam Millman <sam.mill...@gmail.com> wrote:
> Heh indeed :) even using a completely different tech doesn't save you from
> the SQL terminology :)
>
> Np glad to have helped, that's what we are here for :)
>
>
> plus de détails »
Reply all
Reply to author
Forward
0 new messages