I want to know if an entity is just a table in the database modelling context? And which is the difference between an entity and a relation? I know that the relation is the base concept of relational databases and has tabular presentation. Are the entity and the relation the same thing? Note: Do not confuse the relation with the relshionship.
An entity is somting like an object, you can put a name to an entity.
A relation is a "link" beetwen entity, you can put a verb to an entity, in your MCD of your databases.
for exemple :
in your MCD DOG end are entity end part of is the relation
+-------+ +-----+
|DOG | |RACE |
|-------| |-----|
|name |---(part of)----|name |
|age | +-----+
+-------+
in your MPD this MCD become :
+--------+ +---------+
|tDog | |tRace |
|--------| |---------|
|id_tDog | +--|id_tRace |
|nameDog | +--(tRace_to_tDog)--| |nameRace |
|ageDog | | +---------+
|FK_tRace|<-+
+--------+
Related
I am designing a way to store history of a graph in a graph database. I have the following in mind:
History of a node, say Vertex_A, is maintained by creating another history node, say History_Vertex_A. Whenever Vertex_A is modified, a new version node, say Vertex_A_Ver_X, is created. This new node stores the old values of the changed data. A new edge is created between the history node and the version node. Following diagram depicts this idea. Is there a better way to store history of a vertex/node in a graph database?
+------------------+
| Vertex_A (Ver N) |
+---------+--------+
|
+-----------v-----------+
| Edge_Vertex_A_History |
+-----------+-----------+
|
+---------v--------+
| History_Vertex_A |
+---------+--------+
|
+---------------------+----------+----------------+----------------------+
| | | |
+------v-------+ +------v-------+ +--------v-------+ +-------v--------+
| Edge_A_Ver_0 | | Edge_A_Ver_1 | | Edge_A_Ver_N-2 | | Edge_A_Ver_N-1 |
+------+-------+ +------+-------+ +--------+-------+ +-------+--------+
| | | |
+--------v---------+ +--------v---------+ +----------v---------+ +---------v----------+
| Vertex_A (Ver 0) | | Vertex_A (Ver 1) | .... | Vertex_A (Ver N-2) | | Vertex_A (Ver N-1) |
+------------------+ +------------------+ +--------------------+ +--------------------+
Now, say I have the following relation. Vertex_A is connected to Vertex_B via edge Edge_AB.
+----------+ +---------+ +----------+
| Vertex_A +------> Edge_AB +-------> Vertex_B |
+----------+ +---------+ +----------+
I can store the history of vertices as per the above design, but I cannot use that same idea to store history of edges, edge Edge_AB in this case. This is because it won't be possible to have an edge connecting to it's corresponding history vertex. An edge cannot connect to a vertex. So what is the best way to store history of an edge in a graph database?
Your approach is universally working among different graph databases.
One more approach that we are doing with NebulaGraph is to leverage the rank concept in its edge defination.
In NebulaGraph, the factor to define one instance of an edge is: [src, dst, edge_type, rank], where the rank is an int to represent things like transaction_id, timestamp, version or whatever generates multiple between two vertices in one edge type.
note, rank field could be ommited, where the value will be 0, thus it brings nothing new to us with same mind model from other graph databases when using it.
With rank, we could easily design the versioning of edges here. But how could we design the versioning of vertecies then? Our approach will be to introduce an edge with dst-vertex of itself, and put the propertis that could differ from different versions of vertices in this edge, where the rank is the version and the properties are on the edge.
ref:
https://docs.nebula-graph.io/3.2.1/1.introduction/2.data-model/
https://github.com/vesoft-inc/nebula
I wish to use Datastore, but I read that an entity size is limited to 1mb.
I have an entity "Users", which contains around 50k "User". I wonder if the entity size restriction is not too restrictive for my case. And if a day I will have more users, will I be blocked.
This is how I imagine my database, maybe I misunderstood how it's supposed to work:
+--------- Datastore -------------+
| |
| +---------- Users ------------+ |
| | | |
| | +---------- User ---------+ | |
| | | Name: Alpha | | |
| | +-------------------------+ | |
| | | |
| | +---------- User ---------+ | |
| | | Name: Beta | | |
| | +-------------------------+ | |
| +-----------------------------+ |
+---------------------------------+
Where "Users" is an entity which contains entities "User".
Thank you.
Your "KIND" is user, your "entities" are EACH user. So no matter how MANY users you have, as long as EACH user is under a meg, you're fine.
The only limit to the size of the full "kind" is what you're willing to pay in storage. Reading up on this doc, or watching this introduction video could give some high level advice to your situation.
To better understand keys and indexes (another VERY important concept of datastore), I would suggest this video that explains VERY well how composite indexes work and behave :)
In a sequence diagram i am trying to model a loop that creates a bunch of objects. i have found little information online regarding the creation of multiple objects in an SD diagram so i turn to you.
The classes are Deck and Card
Cards are created by fillDeck(), which is called by the constructor of Deck (FYI the objects are stored in an arraylist in Deck).
There are many types of cards with varying properties. Suppose i want 8 cards of type A to be made, 12 of type B and 3 of type C
How would i go about modelling such a thing? this is the idea i have in mind so far, but it is obviously incomplete.
Hope someone can help! thanks!
+------+
| Deck |
+------+
|
+--+-------+--------------+
| loop 8x / |
+--+-----+ +----------+ |
| |-------->| Card(A) | |
| | +-----+----+ |
+--+----------------------+
| |
+--+--------+------|-----------------------+
| loop 12x / | |
+--+------+ | +---------+ |
| |------------------------->| Card(B) | |
| | | +----+----+ |
|--+---------------------------------------+
| | | |
+--+-------+----------------------------------------------+
| loop 3x / | | |
+--+-----+ | | +---------+ |
| |--------------------------------------->| Card(C) | |
| | | | +----+----+ |
|--+------------------------------------------------------+
| | | |
"A sequence diagram describes an Interaction by focusing on the sequence of Messages that are exchanged, along with their corresponding OccurrenceSpecifications on the Lifelines." (UML standard) A lifeline are defined by one object. But that doesn't mean you must keep all objects in lifelines. You should show only these lifelines, that are exchanging messages you are thinking about.
And you needn't show all messages sequences logic on one diagram. In one SD normally you are showing one Interaction. Or maybe a few of them, if they are simple.
So, if your SD is showing one logical concept, it is correct. If there will be another interaction between some objects, you will draw another SD for this interaction, and there will be only objects participating in this second interaction.
UML standard 2.5. Figure 17.25 - Overview of Metamodel elements of a Sequence Diagram
I'm having a bit of trouble designing an ER diagram for a bike shop. The shop contains many bike parts (wheel, gear, brakes etc.) which have different attributes. I have therefore made each part as an entity in order to model the different attributes of theirs. They all contain a quantity attribute, name and price which is made by using inheritance. However, now when I have all these entities they should be mapped to the 'Bike' entity which is a collection of all the parts and the 'Stock' entity where all the parts are listed as well as their preferred amount and minimum amount.
My problem is that I'm not sure how to map the parts to the 'Bike' and 'Stock' entity. In the figure below I've made two different designs. Which one of them is correct, if any at all? Can I model it in a smarter way? (I have removed the attributes for simplification)
Solution 1
Solution 2
I think you are looking at a Bill of Materials type schema, where you could have a Part super-type and as many sub-types as you wish to hold specific details for particular types of Part. The Bill of Materials contains a quantity to hold the number of child Parts required to make the parent Part e.g 2 wheels, 1 frame. This goes all the way up to Bike, which is just another type of Part. The Part can then link into your entities for managing Stock and Inventory.
+-----------------+
| BOM |
+-----------------+
| parent_part_id |
| child_part_no |
| quantity |
+-----------------+
| |
| | +-------------+
| | | STOCK |
+-------------+ +-------------+
| PART |-----| ... |
+-------------+ +-------------+
| part_id |
| part_type |
+---------| ... |---------+
| +-------------+ |
| | |
| | |
| | |
+-------------+ +-------------+ +-------------+
| WHEEL | | GEAR | | BIKE |
+-------------+ +-------------+ +-------------+
| part_id | | part_id | | part_id |
| ... | | ... | | ... |
+-------------+ +-------------+ +-------------+
None of them. Sorry.
First of all, you may want to consider "Wheel", "Gear", "Brake" as a single entity "Part", instead of separate entities.
This makes the diagram more simple. And, rememeber, than there can be more parts, like "chain", "lights", and so on.
So instead of defining a sngle entity for each part, just define a single one: "Part", for all.
Second, Some parts can be parts of another part, and so on. This is called a "recursive" or "self referenced" entity. This may look odd, at first, but, also, makes the diagram more simple.
............................................................
...........+-------------+..................................
...........|.............|..................................
...........|.............|..................................
.........../\............|.........../\.....................
........../ \...........|........../ \....................
........./ \.....Many.|....Many./ \...................
......../ \.1.+-----+----+.../ \...1+----------+..
.......<IsPartOf>--| Part +--< Stores >---+ Stock |..
........\ /...+----------+...\ /....+----------+..
.........\ /.........|..........\ /...................
..........\ /..........|Many.......\ /....................
...........\/...........|............\/.....................
......................./ \.................................
....................../ \................................
...................../ \...............................
..................../ \..............................
...................< Composed >.............................
....................\ By /..............................
.....................\ /...............................
......................\ /................................
.......................\../.................................
........................|...................................
........................|1..................................
...................+----------+.............................
...................| Bike |.............................
...................+----------+.............................
............................................................
Cheers.
There is a database of spare parts for cars, and online search by the name of spare parts. The user can type in the search, for example "safety cushion" or "airbag" - and the search result should be the same.
Therefore, I need somehow to implement the aliases for names of spare parts, and the question is how to store them in the database? Until now I have only one option that comes in mind - to create an additional table
| id | name of part | alias_id |
-------------------------------------------------- ---------------
| 1 | airbag | 10 |
| 2 | safety cushion | 10 |
And add additional field "alias_id" to table containing all the spare parts, and search by this field...
Are there other better options?
If I have understood correctly, it's best to have 3 tables in a many to many situation (if multiple parts have multiple aliases:
Table - Parts
| id | name of part |
-----------------------
| 1 | airbag |
| 2 | safety cushion |
Table - Aliases
| id | name of alias |
-----------------------
| 10 | AliasName |
Table - PartToAliases
| id | PartId | AliasId |
-------------------------
| 1 | 1 | 10 |
| 2 | 2 | 10 |
Your solution looks fine for the exact problem you described.
BUT what if someone writes safetycushion? or safety cuschion? With these kinds of variations your alias lookup table will soon become huge and and manualy maintaining these will not be feasible.
At that point you'll need a completely different approach (think full text search engine).
So if you are still sure you only need a couple of aliases your approach seems to be fine.