I'm slightly new to MySQL and was wondering how to implement a generalisation association in SQL.
In my UML diagram I have a user with two sub-classes (Employee and Manager) that inherit all the attributes of User.
How would I go about writing this in SQL?
Thanks!!
UML Generalisation
There are different ways to implement a generalization. One is to create a table that has all the generalized attributes, plus those of he inheriting classes along with an enumeration, telling which of the specialized attributes are valid. You will have a naming convention too to identify the attributes from the specializing classes. E.g. if your Employee had an attribute degree you'd name it emp_degree or the like.
A second way would be to have a User table and using foreign keys in Employee etc.
All depends on the requirements. There is no silver bullet.
Related
I'm making a JavaFX desktop application. It's a Point of sale system that tracks orders in a restaurant. I am very new to this and things got confusing after I fired up my phpmyadmin to create my database.
This is the relevant part of my UML :
Some examples to clarify the tables' content :
Ingredient table may contain : Flour, sugar, beef, eggs...
ArticleMenu table may contain : Pizza, Burger...
ArticleMenu is made of a bunch of ingredients , but these ingredient can still exist on their own, so it's an aggregation I thought.
The issue is to translate this into a relational database, and especially the aggregation.
What I tried :
in ArticleMenu, the 'recette' attribute is a FK that refrences a row from Ingredient table, the 'recette' attribute is of type ENUM , which can hold many values the user defines when creating a row in ArticleMenu.
Example :
ArticleMenu table has a row that represents let's say Pizza, one of it's attributes is recette of type ENUM and has the values "Cheese, flour, yeast, onions, tomato, mushroom, oil"
My question :
is this an acceptable way of representing an aggregation and what would be the most optimal way?
Edit :
After reading Christophe's answer it's clear that I did not
understand what ENUM is.
The IBM document he linked cleared a lot of confusion I had relating
to this topic.
Stock information shouldn't be part of the ingredient table since
there could be many states of the same ingredient, so I removed
those.
As for the quantities used in each recipie, those will be represented
using the quantity attribute from the recipie table.
So I re-thoought my approach and came up with this design:
Problem with your approach
You implemented what Martin Fowler calls a foreign key mapping, which implements a one to (potentially) many relationship:
Here, Recipe ('recette') would implement a many-to-one relationship between ArticleMenu and Ingredients: one article would have only one ingredient, and one ingredient can appear in many articles.
Moreover the ENUM lets you chose for one row only one value among severals. The ENUM is in fact just a handy replacement for using a number instead of a string.
So, no, it's not the right approach.
Many-to-many association and the hidden table
What you need is to implement a many-to-many association: each ArticleMenu could have many Ingredients, and conversely each Ingredient could be used in many ArticleMenu.
In an RDBMS, this can be implemented using an association table. It's a table taht is not visible in your conceptual model. This association table could for example be called Recipe and have two columns: idArticleMenu and idIngredient. You can then find:
all the ingredients of an article, by looking for every recipe row that has the relevant idArticleMenu.
all the articles in which an ingredient is used, by searching for the idIngredient
Completing your model
Now if you speak of recipe and flour, the next question in your application would be: how many flour do I need to make 1 pizza ?
Unfortunately, this Quantity is not a property of ArticleMenu, since every ingredient of the same article could have a different quantity. It is not either a property of Ingredient, since an ingredient is used with different quantities, depending on the article for which it is used. So where to put this ?
The answer is an association class
Additional advice
You can use the aggregation to express the whole-part relationship. However the aggregation semantic is not clearly defined in the UML specification. So there is no fundamental benefit in using it. You could therefore use a normal association here.
In a design model (conceptual), you should not show in a class the properties that implement a relation. You could show the name of such properties at the other end of the association it will implements. If an implementation model, you could very well show all the columns of a table. The usual practice is then to use a «table» stereotype for each class that would be mapped to a table.
I am trying as an exercise for an exam to transfer a database from the ER model to a relational database.
However, I am very unsure whether my solution makes sense. In particular, the two relationships between location and has makes great problems. I thought I could add one ZipCode as a regular primary key into the table has and a second ZipCode as foreign key. I would be very grateful if someone could help me with this.
My Solution so far:
If you are following Chen ER design with this Chen ER diagram then you need a table for every entity type box and every relationship (association) type diamond and a FK (foreign key) for every participation/role line for a relationship type.
(It is a bad idea to call lines/FKs "relationships" or "associations" in a Chen context because diamonds/tables represent relationship types and lines/FKs represent participations.)
So your Ship tourID would be dropped in favour of relationship/table takes with lines/FKs to Ship & Tour. And you would have two FKs in the has table to Location. It doesn't matter that you need different column names in the relationship table than in the participant table. A FK just says the values in some table & column list appear in some other table & column list. The diagram says the names are start & target; use them.
Don't use a flaccid uninformative name like has. If you picked a better name and/or explained when a triplet of entities satisfied the has relationship then we could know what reasonable designs would be. Eg you may not be using cardinalities correctly. The Chen way is, a number or range tells for some instance of the entity type how many relationship instances it can participate in. Another way is, a number or range tells you for a some combination of entity instances of the other participating entity types how many instances of the line's entity type can participate with it. If the latter has a zero that means a relationship instance can have a NULL. But that can't arise in a Chen design; participating entity instance combinations identify relationship instances and form PKs (primary keys).
However, a Chen design can't express all relational designs. And we can represent the same data as a Chen ER schema by rearranging tables. Eg dropping binary relationship tables that are not many:many and putting FKs (sometimes nullable) into entity tables instead, just as you did with takes, Ship & Tour. Some methods have non-Chen diagrams expressing such designs directly. Others allow it in the move from Chen diagram to schema. You have to ask your teachers whether they care just what variations from the Chen style of ER diagrams and corresponding schemas you are permitted to make.
(It is this dropping in non-Chen methods of explicit 1:many relationships/associations and their representation by FKs that leads to FKs being incorrectly (but commonly) called "relationships" or "associations".)
I'm finding the best way to convert an eer diagram to the corresponding relational diagram. I have a generalization entity with some specializations which have separate relationships with other entities. The generalization entity has in turn a n-to-m relationsip with an entity. The following drawing clarifies the situation:
Eer diagram with specialization and n-to-m relationship.
As the two specialized entities have separate relationships, I should convert them to two separate tables. Meanwhile, I should create a table modeling the n-to-m relationship which relates the entity 'User' to the entity 'Newsletter' (or better, its specializations). How to cope with this problem? I've not found any useful information.
The only possible solution I thought to was to create two separate tables modeling the n-to-m relationship, one linked to 'User' and 'Programming newsletter' tables, one linked to 'User' and 'Travel newsletter' tables. But I'm looking for opinions for that.
I see no problem. I would implement your diagram using the following tables:
User (nickname PK, name, address)
Newsletter (name PK, supervisor, type)
Subscription (user_nickname PK/FK, newsletter_name PK/FK)
Programming_Newsletter (newsletter_name PK/FK, type FK, language)
Travel_Newsletter (newsletter_name PK/FK, type FK, means_of_transport)
I probably wouldn't use user nicknames / newsletter names as keys since I prefer stable compact identifiers, but that's another topic.
I think there are a couple of ways to go about this.
The simplest one, would be to break the assumption "As the two specialized entities have separate relationships, I should convert them to two separate tables". If you keep your specialisations together in a single table, you can use STI (Single table inheritance) for your generalisation. This approach has a drawback though, which is that your table will have many NULL values for those relationships that do not belong to the concrete specialisation.
The other approach, would be to use CTI (Class Table Inheritance). This approach assumes that there will be a specific table for each specialisation of your generalisation. This would get around the NULL problems, but it can potentially introduce a performance problem due to the fact that your code will need to eagerly join from the generalisation table to the specialisation on almost every single query you make to retrieve them.
I don't quite see the issue in the n-to-m relationship between User and Newsletter. You should be able to have a regular intermediate table that creates the association between the two, since there are no further attributes that complement that relationship.
I was studying about relationships in RDBMS.I have understood the basic concept behind mapping relation ship,but I am not able to spot them.
The three possibilities :
one to many(Most common) requires a PK - FK relationsip.Two tables involved
many to many(less common) requires a junction table.Three tables Involved
one to one(very rare). One table involved.
When I begin a project,I am not able to separate the first two conditions and I am not clear in my head.
Examples when I study help for a brief moment,but not when I need to put these principles in to practice.
This is the place where most begineers falter.
How can I spot these relationships.Is there a simpler way?
Don't look at relationships from a technical perspective. Use analogies and real-life examples when trying to envision relationships in your head.
For example, let's say we have a library database.
A library must have books.
M:M
Each Book may have been written by multiple Authors and each Author may have written multiple Books. Thus it is a many-to-many relationship which will reflect into 3 tables in the database.
1:M
Each Book must also have a Publisher, but a Book may only have one Publisher and a Publisher can publish many Books. Thus it is a one-to-many relationship and it reflects with the PublisherId being referenced in the Books table.
A simple analogy like this one explains relationships to their core. When you try to look at them through a technical lens you're only making it harder on yourself. What's actually difficult is applying real world data scenarios when constructing your database.
I think the reason you are not getting the answers that you need is because of the way you are framing the question. Instead of asking “How do I spot the correct type of relationship between entities”, think about “How do my functional needs dictate what relationship to implement”. Database design doesn’t drive the function; it’s the functional needs that drive the relationships you need to implement.
When designing a database structure, you need to identify all the entities. Entities are all the facts that you want to store: lists of things like book titles, invoices, countries, dog species, etc. Then to identify your relationships, you have to consider the types of questions you will want to ask your database. It takes a bit of forward thinking sometimes… just because nobody is asking the question now doesn’t mean that it might not ever be asked. So you can’t ask the universe “what is the relationship between these lists of facts?” because there is no definitive answer. You define the universe… I only want to know answers to these types of questions; therefore I need to use this type of relationship.
Let’s examine an example relation between two common entities: a table of customers and a table of store locations. There is no “correct” way to relate these entities without first defining what you need to know about them. Let’s say you work for a retailer and you want to give a customer a default store designation so they can see products on the website that their local store has in stock. This only requires a one-to-many relationship between a store and the customer. Designing the relationship this way ensures that one store can have many customers as their default and each customer can only have one default store. To implement this relationship is as easy as adding a DefaultStore field to your Customer table as a foreign key that links to the primary key of the Store table.
The same two entities above might have alternate requirements for the relationship definition in a different context. Let’s say that I need to be able to give the customer the opportunity to select a list of favorite stores so that they can query about in stock information about all of them at once. This requires a many-to-many relationship because you want one customer to be able to relate to many stores and each store can also relate to many customers. To implement a many-to-many relationship requires a little more overhead because you will have to create a separate table to define the relationship links, but you get this additional functionality. You might call your relationship table something like CustomerStoreFavorites and would have as its primary key as the combined primary keys from each of the entities: (CustomerID, StoreID). You could also add attributes to the relationship, like possibly a LastOrderDate field to specify the last date that the customer ordered something from a particular store.
You could technically define both types of relationships for the same two entities. As an example: maybe you need to give the customer the option to select a default store, but you also need to be able to record the last date that a customer ordered something from a particular store. You could implement the DefaultStore field on the Customer table with the foreign key to the Store table and also create a relationship table to track all the stores that a customer has ordered from.
If you had some weird situation where every customer had their own store, then you wouldn’t even need to create two tables for your entities because you can fit all the attributes for both the customer and the store into one table.
In short, the way you determine which type of relationship to implement is to ask yourself what questions you will need to ask the database. The way you design it will restrict the relational data you can collect as well as the queries you can ask. If I design a one-to-many relationship from the store to the customer, I won’t be able to ask questions about all the stores that each customer has ordered from unless I can get to that information though other relationships. For example, I could create an entity called "purchases" which has a one-to-many relationship to the customer and store. If each purchase is defined to relate to one customer and one store, now I can query “what stores has this customer ordered from?” In fact with this structure I am able to capture and report on a much richer source of information about all of the customer's purchases at any store. So you also need to consider the context of all the other relationships in your database to decide which relationship to implement between two particular entities.
There is no magic formula, so it just takes practice, experience, and a little creativity. ER Diagrams are a great way to get your design out of your head and onto paper so that you can analyze your design and ensure that you can get the right types of questions answered. There are also a lot of books and resources to learn about database architecture. One good book I learned a lot from was “Database System Concepts” by Abraham Silberschatz and Henry Korth.
Say you have two tables A and B. Consider an entry from A and think of how many entries from B it could possibly be related with at most: only one, or more? Then consider an entry from B and think of how many entries in A it could be related with.
Some examples:
Table A: Mothers, Table B: Children. Each child has only one mother but a mother may have one or more children. Mothers and Children have a one-to-many relationship.
Table A: Doctors, Table B: Patients. Each patient may be visiting one or more doctors and each doctor treats one or more patients. So they have a many-to-many relationship.
An example of one to one:
LicencePlate to Vehicle. One licence plate belongs to one vehicle and one vehicle has one licence plate.
I am trying to lay out the concept for a Relational DB and I ran into some conceptual Problems:
If I have multiple discrete Entities that are "nested" in each other/have a hierarchy e.g.:
Bosses can have multiple Employees. These employees have different Projects they do and One Project has again multiple sections.
So
B1-Bn:
E1-En
P1-Pn
Section1 -SectionN
How would that be best mapped in a database?
Or in other words, how is this hierarchy best mapped in a relational db?
Now I have Costumers that interact with these Employees.
They are met by the bosses
Then they decide which employee will work for them.
Then they are assigned Projects, with one or more sections.
How would that be best mapped.
the Relations 1-n, m-n, 1-1: Can they be used for e.g.:
This is a Foreignkey because of the 1-n relationship.
This is a ManytoManyField because of the m-n relationship.
And is there a excellent online tool to better understand/visualize that.
Thanks so much for your time!
You may want to follow a course on relational database design; this subject takes more than a few days to explain or master. But you are on the right track.
The first thing you may be seeing is a hierarchy, but before you know it there will be relationships that aren't hierarchical, so a network is formed.
This is why relational databases do not work with hierarchies.
You identify different types of entities and have one table for each type.
For each entity type you identify the properties of such entities - each property will be a column of the table.
If a property does not have an atomic value, but a structured value, these structured values must be regarded as an entity, and must be given its own table, and the property will be a foreign key referring that table.
In this way, you will form a network of tables linked by foreign keys. This is called an entity-relationship diagram. Many designers advocate creating such a diagram first, without mapping the entity types to tables directly. They allow many-to-many relationships between entity types in the diagram. A foreign key between tables on the other hand is always many-to-1 or 1-to-1. So these designers have an "implementation" step in which they introduce an additional table for each many-to-many relationship. Personally I don't use many-to-many relationships in my diagrams to begin with.