At a very basic level, the MongoDB program stores chunks of data (“documents”), each one under a key. To look up the data, you give it the key and it gives you that chunk of data. It stores the data in a format called BSON. BSON is a version of JSON. So a set of data stored using MongoDB can be thought of as a collection of JSON files, with a key for each one.
1: { "hello": "world" }
2: { "foo": 1, "bar": 3 }
3: { "somedata": [1,2,3,4,5] }
4: { "false": true, "true": false }
The data can be anything, in any shape. So it’s not as if you can guarantee something like “each item in this database table represents a cat owner, and each of those owners has a name (string), email (string) and some cats (number)”. It’s completely freeform, there aren’t any restrictions. It’s just up to you to make sure that every time you save a new user, they have the correct set of details.
Compare to a relational database (for example MySQL), where you explicitly set up columns in a table, and you can make sure that those columns are filled with the correct type of thing, and the database program will ensure, mathematically, that the data is correct. That when you query it, the fact you are asking it to prove is actually factual. So for example, if you ask a relational dB “how many cats does the owner with the ID of 1 have”, it’ll tell you. If you ask the same question of Mongo, the person who uploaded the entry with ID 1 might have just saved {"hello": "world" } to the dB, so you ain’t getting the information you want, you just get garbage.
If you want to get around this problem (you don’t need to – it’s perfectly reasonable to want to store completely unstructured data), you can put a layer of software in front of Mongo which lets you define what the shape of the data being stored is. So instead of hitting mongo directly, you go through this layer, and the layer makes sure that the data is correct, that it conforms to a schema.
That layer is Mongoose. And the second thing you’ve asked about, object modelling, that means that you describe the shape of the data in the database as JS objects and that is what you deal with, rather than the dB directly. So remember Mongo stores data as a type of JSON. So to save, you have to take the data and convert it to BSON. To query, you need to take the BSON, and convert it to JS. With Mongoose, it automatically maps things back and forth between BSON and JS. And further to that, it will do magic based on the schemas to a. make sure the data conforms to what you want and b. allow you to query/update/etc things via an interface based on JS objects, which, if you’re a JS developer, is likely to be much easier (likely doing quite a bit of work there mind, there are good arguments for and against using these kind of tools, it’s context-dependent)