I'm developing a Pokémon app to learning how work pokemon internally. My question is what is best option to model?
A little context:
A Pokémon has types (Water, Fire, Grass...)
A type has effectiveness and weaknesses.
Example:
Efectiveness
Weaknesses
Water
Fire
Grass
Fire
Grass
Water
1.- Can i model a table with type but how can relation them?
2.- I can use graph teory, but how do i represent it in database?
This development was born out of the same curiosity.
Thanks!
Create table with relation, but i think is not efficient
This is a many-to-many relationship. Multipe types can have the same strength, and a type can have multiple strengths. Many to many relationship require an intermediate bridge table. And in this case, it's a loop back to the same table, as a type is relating to a type. I don't know how to represent ERD symbols in this dialog box, but this should give you the basic picture. Three tables are pictured below, Pokemon, Types and TypeModifiers:
Pokemon TypeModifiers
------- -------------
[ type id ] --> Types <--- [base type id
[type id] <---- modifier type id
strength-or-weakness code]
Create a foreign key on TypeModifiers.base_type_id to point to Types.type_id
Create another foreign key on TypeModifiers.modifier_type_id to also point to Types.type_id
This will allow you to model any possible relationship between a type and all other types. You could do strengths and weaknesses as separate tables, but it's simpler on queries if you combine them and differentiate with a column value, e.g. 'S' vs. 'W'.
Related
This is the description:
Draw an Entity-Relationship diagram for Poke-Hospital which provides
medical service to pokemon.
Each pokemon has an appointment with one of the nurse Joys. In
addition to recording the name, type and trainer of each pokemon, the
system needs to keep track of the multiple types of sickness being
diagnosed for the pokemon. During an appointment, the nurse will
always prescribe medicine. It is required to record the date, time and
dosage of the medicine. A pokemon may need to take more than one
medicine at a time. Each medicine is stored with its name, brand and
cost of purchase. There is no restriction on the amount of medicine to
be prescribed by any nurse.
Within an appointment, a pokemon may need to undergo procedures such
as a surgery and/or diagnosis. Each procedure requires different type
of rooms and a list of equipment. The date, time and the actual room
of the procedure need to be recorded.
A procedure may be performed by more than one nurse. A nurse is
involved in the procedure based on the training skills that she has
completed. Not all nurses are qualified to perform procedures.
Name, pager number as well as office number for each nurse most be
known. Your diagram should show the entities, relationships and their
attributes, and the cardinality of any relationships. Mark the best
primary key for each entity by underlining it.
This is my solution:
Here are my questions:
Should I use Have Appointment as associative entity?
Should I remove 2 relationships Undergo and Prescribe and connect 2
entities Procedure and Appointment Medicine directly to Have
Appointment associative entity? Will the ERD still right then?
If it's wrong, what about the same as question 2 and I turn the Have
Appointment associative entity into a relationship?
I feel really confused about the difference between using associative entity with a relationship (like in this post Enrollment with Teach and Teacher: When to use Associative entities?) and using ternary relationship (connect Teacher directly to Enrollment relationship instead of changing Enrollment to an associative entity and have the Teach relationship).
Should I use Have Appointment as associative entity?
No, I believe it should be a regular entity set. You gave it its own identity - the ID primary key - which I agree with, but that should've corresponded with a change in element type. Associative entity sets (AES) are relationships first, which means they're identified by the (keys of the) entity sets that they relate.
This is a topic that's widely confused, since AES in the entity-relationship model are different than in the network data model. The latter is intuitively more familiar to developers, since it's essentially a model based on records and pointers, but since it only supports directed binary relationships, anything more complicated - many-to-many relationships as well as ternary and higher relationships - need to be represented as AES. In this model, AES are identified by a surrogate ID, since composite keys generally aren't supported either.
The entity-relationship model supports n-ary relationships and composite keys, and so doesn't need AES nearly as frequently. One situation that can't be represented by regular entity sets and n-ary relationships is when a relationship needs to be the subject of a further relationship.
For example, let's look at the relationship between Procedure and Nurse to represent the nurses involved in a procedure.
I prefer the look-across convention for cardinality indicators - a nurse can perform 0 or more procedures, while a procedure requires 1 or more nurses. Anyway, the relationship Perform here is identified by the composite primary key (ProcedureID, NurseID).
Now, if we wanted to track the equipment used by each nurse in the performance of the procedure, we might think a simple ternary relationship would do the trick:
but that relationship would be identified by (ProcedureID, NurseID, EquipmentID), preventing us from recording nurses that assisted in the procedure without using any equipment. What we need is two separate relationships:
(ProcedureID, NurseID)
((ProcedureID, NurseID), EquipmentID)
with an FK constraint from the second to the first to prevent nurses not assisting in the procedure from handling the equipment.
Back to Have Appointment - it's not a relationship between pokemon and nurses (a pokemon can see the same nurse multiple times), it's an event that involves pokemon, nurses, procedures and medicine. It's best handled as a regular entity set with relationships to the other four. As for identity, I imagine a pokemon or nurse can only have one appointment at a time, so we could choose (PokemonID, DateTime) or (NurseID, DateTime) as a natural key. However, in practice we usually identify events by a surrogate ID since events span an interval which most DBMSs can't handle effectively as a primary key.
Should I remove 2 relationships Undergo and Prescribe and connect 2 entities Procedure and Appointment Medicine directly to Have Appointment associative entity? Will the ERD still right then?
No, I think you should add relationships between Pokemon and Have Appointment, and between Nurse and Have Appointment, after converting the AES to a regular entity set.
If it's wrong, what about the same as question 2 and I turn the Have Appointment associative entity into a relationship?
Answered above.
For example, I have a table for "Device" that includes attributes “make” “model” and then “device type”. Now I want to have tables that represent appropriate attributes for each "device type". For device type “Display” I want to have attributes such as “height”, “width” and “resolution”. But for the device type “projector” I want to have different attributes such as “brightness”, “light engine”, “lens type” etc… What is the best way to design for these type of data models. I want to be able to have a list of all devices in a table but then be able to drill down into the specifics of each device type. Hope this makes sense, I am still learning database design. Thanks.
If there are many types of devices, I would have these tables :
Table Device with attributes ID Make and Model, and not DeviceType.
Table Type with attributes ID and Name.
Table Display with attributes Height, Width, ...
Table Projector with attributes Brightness, LightEngine, ...
And finally, a table to link any device to a device type, such as DeviceType, with attributes DeviceID and TypeID.
This is what is known as either a "Category Relationship" or (more commonly today) "Multiple Table Inheritance". There are at least three different, viable ways to implement one depending on the constraints. This article here: http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server does a pretty good job of explaining how to implement them.
With relational database, you can go ahead with your design.
Your parent table would be:
1.(DEVICE) will have columns(primaryKeyId, make, model, deviceType...).
Child tables would be:
1.(DISPLAY) will have columns like (id_foreignKey, type, height, width...)
2.(PROJECTOR) will have columns like (id_foreignKey, brightness, light engine...)
Based on the id you store in child tables referenced by parent table primary key, you can drill down to specifics of each device type.
Your deviceType column would have numbers 1 (display), 2 (projector) ....
You can learn from below link:
https://www.tutorialspoint.com/dbms/er_model_to_relational_model.htm
I would recommended this would be an adaptation of many-to-many tags schema design. It would allow for most flexibility for your use-case.
Here is an example of this method based on your question.
And here is another similar method - which is more so targeted towards only handling device_type attributes.
As you can see, both methods would fit your requirements well - it comes down to how much flexibility you require.
Here are some references that may give more insight:
http://lekkerlogic.com/2016/02/site-tags-using-mysql-many-to-many-tags-schema-database-design/
http://tagging.pui.ch/post/37027745720/tags-database-schemas
Imagine that you have to model incidents. There's four types of incidents (could be more). They all share some characteristics. So, the main shared fields would be in a supertype table called incidents and there will be one table per incident-type having incident_id as a FK. I could even have a incident type table to help me enforce that one incident id will be of one type only. This is all very text book, BUT, I'd like to know what's the best way to model the case when 3 of these incident types share a subset of fields and these fields are mandatory to them (so I can't put then in the supertype table, can I?). On top of that, some of those fields shared only by 3 of the incident types have a limited set of values (i.e. types of rock) and that's a typical look-up table.
So, should I repeat all these fields in the 3 incident tables and have a look-up table being Foreign keyed to these 3 tables? Should I have intermediary tables?
Thanks in advance,
Joe
I am designing a database and as i do not have much experience in this subject, i am faced with a problem which i do not know how to go about solving.
In my conceptual model i have an object known as "Vehicle" which the customer orders and the stock system monitors. This supertype has two subtypes "Motorcar" and "Motorcycle". The user can order one or the other or even both.
Now that i am at the logical design stage, i need to know how i can have the system allow for two different types of products. The problem i have is that if i put each of the objects separate attributes into the same relation, then i will have columns that are of no use to some objects.
For example, if i just have a generic table holding both "Motorcars" and "Motorcycles" which i call "Vehicles" and all of their attributes, the cars will not need some of the motorcycle attributes and the motorcycle will not need all of the car attributes.
Is there a way to solve this issue?
The decision will need to be guided by the amount of shared information. I would start by identifying all the attributes and the rules about them.
If the majority of information is shared, you might not split into multiple tables. On the other hand, you can always split tables and then join into a view for ease of use.
For instance, you might have a vehicle table with only share information, and then a motorcar table with a foreign key to the vehicles table and a motorcycle table with a foreign key to the vehicles table. There is a certain difficulty ensuring that you don't have a motorocar row AND a motorcycle row referring to the same vehicle, and so there are other possibilities to mitigate that - but all that is unnecessary if the majority of information is common, you just have unused columns in a single vehicles table. You can even enforce with constraints to ensure that columns are NULL for types where they should not be filled in.
Excuse the poor title, i can not think of the correct term.
I have a database structure that represents objects, objects have types and properties.
Only certain properties are available to certain types.
i.e.
Types - House, Car
Properties - Colour, Speed, Address
Objects of type car can have both colour and speed properties, but objects of type House can only have colour, address. The Value for the combination of object, type, property is stored in a values table.
All this works, relationships enforce the above nicely.
My dilemma is that I have another table i.e Addresses. This table has AddressID.
I want to somehow join my address table to my object values table.. is there a neat way to achieve this??
[UPDATE] - More detail
I already have 5 tables. i.e.
Object
Properties
ObjectTypes
ObjectPropertyValues
ObjectTypeProperties
These tables have relationships which lock which property values can be assigned to each type of object.
An object maybe have a name of 'Ferrari' and the type would be 'car' and because the type is car I can set a value for the colour property.
The value though is numeric and I want to be able to join to a colourcodes table to match the id.
First, a "relation" in Relational Databases is a table - it does not refer to the relationships between tables. A relation defines how pieces of data are related - to a key.
In relational modeling, each entity is normalized, so one model for you would be 4 tables:
Car (Colour-FK, Address-FK)
House (Colour-FK, Speed)
Colour (Colour-PK)
Address (Address-PK, Address-Data)
In relational model, cars are not houses and you typically would be extremely unlikely to model them in the same table.
One might argue, that in fact, the valid colours for houses and cars are very different (since the paints are not equivalent), and thus one would not ever combine the two tables based on colour in a real world application.
Possible other modelling considerations might be where the car is garaged - i.e. an FK to a House or an FK to an Address - interesting problem there. Then if you had keys to cars and houses, they could both be part of key rings, in which case you would probably model with link-tables representing the keys.