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.
Related
Good Morning all. I'm trying to write some of my first scripts and I'm having a difficult time doing so. I'm trying to match data from one file to another, and add a label to that row in the original.
I'm using two different data sources, to accomplish this and there are tens of thousands different rows to match. I'm trying to take one column of zip codes in data source one, match it to the same zip codes in a data source two, and add a new column labeling the location in data source one. see example below.
Data Source One:
|A | | B |
|13329 | X |
|22193 | X |
|13211 | X |
Data source two:
|A | | B |
|13211 | Syracuse |
|22193 | D.C. Metro |
|13329 | Utica Rome |
New Data Source one:
| A | B | C |
|13329 | X | Utica-Rome |
|22193 | X | D.C. Metro |
|13211 | X | Syracuse |
New Data Source One is the desired end state. I am dealing with rows that will have no new labels and can be labeled as N/A or NA (whichever way is fine). I hope I have explained the problem and the desired result well enough. Please help.
More commonly than Matching and labeling this is called joining.
join <(sort DS1) <(sort DS2)
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|<-+
+--------+
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
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.