I am following a book on Fundamentals of Database Systems by Elmasri & Navathe. In the book there is an Entity called DEPARTMENT and it has a multivalued attribute called location. I could not figure out a way to represent location in my ER Diagram which should have an identifying relation with the department entity. Should I draw an Entity named LOCATION and create a relationship with the DEPARTMENT entity or is there another way to represent multivalued attribute in MySQL Workbench.
The EER implementation in MySQL Workbench is not a full implementation the relationship model. It rather focuses on things that can be represented in a MySQL database. That means things like inheritance or multi-valued attributes cannot be modelled there. And I'm also not aware of a way to simulate that, unless you use another entity that has all the attributes which the original attribute needed.
In your case it makes sense to have a location entity that has a relationship with the department entity. Not sure if that should be an identifying relationship, since a location is not mandatory, is it? E.g. it could be a department is stored that no longer exists and hence has no location.
Related
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 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.
For example if I have 20 tables, I have to design it by section? i.e
CLIENT (id, name...) -- orders -- ODERS_DETAIL(id, products...)
.
.
.
lives --- ADDRESS(...)
Or I can use The MySQL Workbench EER Model (To me, it looks like the Pysical Model)?
Or like this: Data Modeling Levels
Well, I would not do it in code. That is for the RDBMS itself.
MySQL EER Workbench does not do true entity modeling - it is modeling tables, you are correct.
If you want true ER modeling I suggest Oracle's newly released ('Early Adopter') SQL Developer Data Modeler.
It is pretty easy to use, is free and can forward and reverse engineer models to tables. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html
When in doubt, design a table that is totally flat, and then determine where you have duplicated data, these can be considered for tables (entities).
The "ER model" defines entities unto themselves and allow the reference of entity-to-entity (table-to-table) through a separate relation. If you can remove yourself from thinking about foreign keys in your entities and focus on the relations in their own separate table.
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.
I'm playing around with LinqToSQL using an existing multi-lingual database, but I'm running into issues mapping a fairly important one-to-one relationship, so I suspect I am using the feature incorrectly for my database design.
Assume two tables, Category and CategoryDetail. Category contains the CategoryId (PK), ParentId and TemplateId. CategoryDetail contains the CategoryId (FK), LanguageId, Title and Description (in the appropriate language), with a combined PK of CategoryId and LanguageId.
If I drag-and-drop these tables into the LinqToSQL designer, the resultant object model has Category with a collection of CategoryDetail objects, which should never be the case. I'd like to be able to filter on LanguageId at the DataContext level, meaning that the whole Category is encapsulated within Category.CategoryDetail, not all language version encapsulated within Category.CategoryDetails.
This database worked fine on my old object library (an old-school custom BOL and DAL), but I fear that LinqToSQL would require this to change in order to give me the required result.
What is the best way to make this relationship (and language filtering) as seamless as possible?
You can view properties of the association. (Right click on the line representing the association and show properties.) The properties will tell you if it is a one-to-one or one-to-many relationship. This is reflected in code by having either a single entity association (one-to-one) or an entity set association (one-to-many).
I would have to assume cant be a true 1 to 1. Sounds like you have a PK of CatID and Lang ID on the Cat Details table. That would explain why its putting a collection. I could be wrong as you didnt mention the PK's of the CatDetails table
EDIT: A combined Pk of CatID and Lang ID makes that a 1:m relationship, and Linq to SQL is actually doing the correct thing. The only way it could possibly be a true 1:1 is if you had a lang ID on the cat table as well and that was part of the FK. I htink you may have to rethink what you want to do, or how you want to implement it.
I think LINQ to SQL models the database structure directly.
You have two tables so it creates 2 objects.
Have you had a look at LINQ to Entities this allows you to create another layer above the database strucure to make for more readable classes.
Since you don't have a 1:1 relationship the mapping alone will not provide the desired functionality. However it is easy to provide a method in the parent auto-generated class that does the job:
public partial class Category
{
public IEnumerable<CategoryDetail> GetDetailsByLanguage(string langID)
{
return this.CategoryDetails.Where(c => c.LangID == langID);
}
}