I usually find everything I need, but there is first time for everything.. :D
I am trying to create a conceptual data model and I dont know how to properly show M:N relationship, which by default should not be included, but still you can assign verbs and directions of abstract entities. So let's say we have "Projects" and we have "Project roles", how do I properly show relationships? Can I have 2 arrows as showed in the picture or do I have to add join table and ?? I can't wrap my head around this..
Thank you so much in advance :)
enter image description here
A conceptual data (or information) model can be created with a suitable modeling language, such as ER diagrams or UML class diagrams. Both languages have a concept and a visual notation for many-to-many associations (or relationship types). Simply follow their definitions. Since there is no standard for ER diagrams, it's easier/preferable to go with UML.
For showing a many-to-many association between two classes (representing entity types), you draw a connection line and annotate it with an asterisk ("*") at both ends.
Notice that a join table is a database implementation, and not a modeling concept.
Related
I've been asked by my teacher to make the ER diagram of a certain library. Here is a very simple and not complete ER diagram only to illustrate my point:
Searching the library's website I found exactly the attributes I need for the customer, for the copies the book etc. However, the book is not the only thing provided by the library. The library provides music-CDs , journals, DVDs and many more leading to 20 different kinds of items in total.
One very ugly solution would be to create a different entity for all these items and connect each one of them with the copy entity. And this seems unavoidable since each item type has different attributes. A book for example has ISBN and a journal the ISSN. Looking at all the attributes of each item the only thing they all have in common is a title.
Is there a better way to do the ER diagram?
unfortunately no, he is asking for an academic solution and the way to represent the mini-world in er is 1 entity type per object. this is my vision to ER diagrams in its simplest academic form.
if you continue to sum entity types together, your entire mini world will be one entity type.
I'm new to data modelling and have started following tutorials to learn more.
I am trying to create a model for a hypothetical scenario and am struggling to validate what I have created to see if it is what would be considered a correct data model.
Essentially all im trying to do is correctly store data in a normalised form. In my scenario there are 3 types of people and each share some attributes and have one set of contact details each.
Does the below data model look feasible?
The relationship between person and one of defendant, magistrate, or staff-member is a case of the class/subclass pattern. There are two common ways of modeling this pattern in relational tables.
One way is called "Class Table Inheritance". You can find out more by visiting this tag: class-table-inheritance or by searching the web for Martin Fowler's treatment of the same subject. Your design resembles this design.
Another way is called "Single Table Inheritance", which you can also research the same way. single-table-inheritance. It's simpler, and works ok in some cases. You deal with fewer joins, but you deal with more NULLS.
Many people who go for class table inheritance also apply a technique called "Shared Primary Key". shared-primary-key. Using this technique, Defendant, Magistrate, and Staff_Member would each use a copy of person_id as the primary key. This primary key also functions as a foreign key. Shared primary key enforces the one-to-one nature of the IS-A relationships that exist in this case.
If you want to go further in data modeling, you might want to learn ER modeling as a distinct data model from the relational model. What you've done here is essentially to use ER diagramming to diagram a relational model. There's nothing wrong with that, but it obscures a whole new field of study, generally called conceptual data modeling.
If you generate an ER model at the conceptual level, you don't attempt to implement it in terms of tables. There is a diagramming convention in ER that goes under the name "generalization/specialization" that allows you to depict a class/subclass situation, while remaining silent on how it's going to be implemented.
Conceptual data models have an area of usefulness, in addition to relational data modeling. What makes conceptual data models useful is precisely the fact that they present the information requirements without stating how those requirements are going to be met.
Once you are proficient at creating conceptual data models, it's not hard to convert one of them to a relational model.
This may be more than you bargained for, but since you are taking on learning modeling, I thought I'd survey some of the field for you.
This is probably a simple problem for an experienced database developer, but I'm struggling... I have trouble translating a certain ER diagram to a DB model, any help is appreciated.
I have a setup similar to slide 17 of this presentation:
http://www.cbe.wwu.edu/misclasses/mis421s04/presentations/supersubtype.ppt
Slide 17 shows an ER diagram with an Employee supertype having an Employee Type attribute and as subtypes the Employee Types themselves (Hourly, Salaried and Consultant), which is very similar to my design situation.
In my case, suppose Salaried Employees are the only ones that can be bosses of other employees and I wanted to somehow indicate if a certain Salaried employee is the boss of the Hourly and/or Salaried Employee and/or Consultant (either, none or both), how could that be designed in a database model, also considering these are one-to-many relationships?
I can put a PK-FK relationship between them, which would result in all tables having two FKeys and (like Consultant having FK_Employee and FK_SalariedEmployee) and SalariedEmployee referencing itself, but I keep thinking that might not be the wisest solution....although I'm not sure why (integrity issues?).
Is this or an acceptable solution or is there a better one?
Thanks in advance for any help!
Your case looks like an instance of the design pattern known as “Generalization Specialization” (Gen-Spec for short). The gen-spec pattern is familiar to object oriented programmers. It’s covered in tutorials when teaching about inheritance and subclasses.
The design of SQL tables that implement the gen-spec pattern can be a little tricky. Database design tutorials often gloss over this topic. But it comes up again and again in practice.
If you search the web on “generalization specialization relational modeling” you’ll find several useful articles that teach you how to do this. You’ll also be pointed to several times this topic has come up before in this forum.
The articles generally show you how to design a single table to capture all the generalized data and one specialized table for each subclass that will contain all the data specific to that subclass. The interesting part involves the primary key for the subclass tables. You won’t use the autonumber feature of the DBMS to populate the sub class primary key. Instead, you’ll program the application to propagate the primary key value obtained for the generalized table to the appropriate subclass table.
This creates a two way association between the generalized data and the specialized data. A simple view for each specialized subclass will collect generalized and specialized data together. It’s easy once you get the hang of it, and it performs fairly well.
In your specific case, declaring the "boss of" FK to reference the PK in the Salaried Employees table will be enough to do the trick. This will produce the two way association you want, and also prevent employees who are not salaried from being referenced as bosses.
Where can I learn more about Conceptual Data Model? I have to create a schema based on the convention in the image below.
I don't understand the "bubble" (or relationship) between the two entities. What should be the name of a relationship (verb, nom, etc.)?
Is there books or websites which cover this data modelisation theory? What is the name of those diagram? I googled as much as I can around "Conceptual Data Model" and I didn't find anything similar to the image above.
Thanks for the help.
P.S. I will be using Open ModelSphere "Conceptual Data Model".
Try learning the Entity Relationship Model : http://en.wikipedia.org/wiki/Entity-relationship_model
And also the Unified Modeling Language : http://en.wikipedia.org/wiki/Unified_Modeling_Language
Here is one book by Korth: http://www.db-book.com/ for starting DBMS. Have a look at the ER-Model chapter.
For UML have a look at : http://www.amazon.com/UML-Distilled-Standard-Modeling-Language/dp/020165783X?tag=particculturf-20
I created a class diagram for a system and now I have to model it into a real system. This means converting it to a database.
Now there is a base class which has just a few attributes, but there are many classes that inherit from it. Now my checklist for converting says I have to create a table for every class.
I don't know how to handle the inheritance, I can see that associations are done with PK and FK's but what about subclasses?
Is there some article which handles that or is there someone who can explain it to me?
Thanks in advance,
You have three alternatives to translate class hierarchies into relational tables:
- Create only a table for the superclass (all attributes and associations of subclasses are moved to the table corresponding to the superclass with the possibility of taking a NULL value)
- Create only tables for the subclasses: All attributes and associations of the superclass are repeated in each subclass
- Create tables both for the superclass and for each of the subclasses. In this case, the PK of the subclasses is at the same table a FK to the superclass (this ensures that all identifiers in a subclass table correspond to an existing identifier in the superclass table. A join between both tables allows to recover the full information of the element)
The best strategy depends on the problem (for instance, the number of attributes in each class, the number of levels in hierarchy, whether the hierarchy is disjoint or not,...)
If you want to see some examples, you can upload your hierarchy to the UMLtoDB online service http://modeling-languages.com/content/uml2db-full-code-generation-sql-scripts-databases
Drop all that UML nonsense - keep it simple. Its just amounts to duplication for no gain. Does Microsoft or Sun publish UML for dOT NET or Java... FOrgetting the odd sample, the majority of these frameworks dont have any official UML anywhere.
Usually, you design your datamodel (database tables/PK/FK etc.,) in parallel when you design your actual class diagram. After identifying all the cadidate classes and the dependencies on each of the classes, you will probably go on with the design sequence diagram. By this time, your data model should have been finalized.
I cannot understand your situation here, but IMO the process that you follow seems a bad idea to me.