Below is the ER diagram with relation among 5 different entities.
My question:
1)
Each of these 5 entities a class as per OOP terminology?
2)
Can you help me understand the meaning of relation(different types of lines) among these 5 entities? Line with a little bubble/ with an angular shape /text
This is not an UML diagram at all, but an entity-relationship (E-R) diagram and typically shows the DB design. You can easily google it to find the detailed notstional rules, I could quickly find this page:
http://www.google.de/imgres?imgurl=http://docs.oracle.com/cd/B12037_01/java.101/b12021/img/entity_d.gif&imgrefurl=http://docs.oracle.com/cd/B12037_01/java.101/b12021/dev.htm&h=1780&w=1556&tbnid=vbXfAtrAAIq5_M:&zoom=1&tbnh=97&tbnw=85&usg=__vyr0LMggQHqYtI8Q6Ix-722jJwg=&docid=3LbfUSlxwqfpMM&client=firefox-a&sa=X&ei=iX1HU5awEImN7Qbf6IGwDg&ved=0CEsQ9QEwBA&dur=1439
If you want to model DB in UML, you can still do it, using class diagram and eventually restricting permited relationships to those available in non-OO modelling.
Related
I am having trouble with producing a ERD model using UML for a piece of work regarding an attendance monitoring system in Universities.
The entities I have are:
Student
Course
Module
Grade
Class
Attendance Log
Please could anyone help to improve it?
See draft ERD for basic understanding -->
This is just opinion, so take it for what it is:
Is there a relationship between Module and Course? Doesn't a Course comprise Modules?
You have identifiers for Primary Key (PK) which is an RDBMS concept rather than UML Class models. You might want instead to stereotype your identity attributes as <<unique>>.
If you are producing an ERDs (as opposed to a UML Class model) then you might want to consider how you will resolve the many-to-many relationships. Clearly m2m is not a structure that RDBMS can manage without having some sort of join entity.
Attendance Log may be better named as a Student Class Attendance. I assume this is there to record which Students attended which Classes, so it's a join entity.
I would recommend reading Eric Evan's "Domain Driven Design", this might help identify the main entities, their satellites and how they relate.
I want to store information about song files which they are categorized by:
1. genre for example: pop, rock, classical etc.
2. instrument used like piano violinn etc
3. Artist
Each song has many instruments. Each song has many artist.
So all of the relations are many-to-many. How can I implement this? Is it good idea to make many-to-many relation between song entity and those three category type entities? or should I only have a single category entity that inherits those sub categories?
thanks in advance
The instrument and the artist are both examples of "has-a" relationships. The genre is an example of an "is-a" relationship. Has-a and Is-a relationships are modeled quite differently in relational database design. A song is a pop song, or a song is a rock song. (I presume that a song can be both pop and rock, but that's not clear in your description).
Has-a relationships are more common, and are generally covered in any good tutorial. Is-a relationships are often not given enough coverage in those same tutorials. If you want to get some articles about ER modeling of is-a relationships, lookup "generalization/specialization". This will explain how to depict one of these relationships but not how to design tables to fit.
If you are familiar with object modeling, your easiest handle on the concept is known as class/subclass pattern aka type/subtype. This is straightforward, but it depends on built in support for inheritance. This support is generally present in any object system, and does most of the hard work for you. If you are designing a relational database you come face to face with the fact that the relational model does not directly support inheritance. This means that you have to design tables that mimic the benefits of inheritance, unless you are willing to use SQL extensions available in your dialect of SQL.
Two relatively standard designs are known by the names of these two tags:
single-table-inheritance
class-table-inheritance
You can get a brief description by reading the Info tab of each of these tags. You can get an even better description by looking up Martin Fowler's treatment of these two patterns.
The single table solution will help you create a single table for all song files, with columns that pertain to any or all of the categories.
The class table solution will help you design one table for the song files and one table for each genre. It will be helpful if you use the shared primary key technique and thereby cause each entry in a genre table to "inherit" its ID from the corresponding entry in the song file table. You have to make this inheritance happen by extra programming when you go to insert a new song file.
Which one is better? It depends on your case. You decide.
I wanna know if there exists conceptual framework or documented techniques to study how to map entities classes to database tables??
Before I was using JPA (Java Persistance API) to map one table -> one entity class, this is: each table's row represented by one object class. Is it the most common/correct way? Has these patterns specific names?
Thanks a lot.
One table to one class is called the "Active Record" pattern. One alternative pattern people use is the Repository pattern. DDD (Domain Driven Design) has the concept of Aggregate Roots which also plays in this space. You should be able to do some reading on that terminology. I am personally not in love with any of those patterns, they all have pros and cons.
For me, there is no recipe, formula or pattern for the ideal class to table relationship. The key point to mapping is that it acts as an adapter layer, isolating the table structure from the entity structure.
If you are designing your application and tables at the same time, I think you should design your tables to minimise round trips, getting as much data to hydrate your entities as possible. Then let your mapper(s) build the entities and any appropriate associations. This might lead you to denormalise your table structure a little more than you might normally.
My assignment requires that I have an ER diagram that shows the dependencies between the objects in my solution. Mine consists of several procedures, tables, a trigger and a sequence. Does anyone know if these objects are permitted in a SQL ER diagram? I ask this because the example shown by my lecturer consisted only of tables. If these objects are allowed in an ER diagram, what is the proper way to represent them?
No, an ER diagram should not contain procedures, triggers nor sequences.
An Entity-Relashioship Diagram is used to represent the relashionships between entities in a database. Procedures, triggers and sequences do not contribute to the relashionship representations.
ER Diagram don't have any particular representation of triggers because ER-Diagram is logical design of Database. BUT we use Strong entity and weak entity symbols to show the dependence of tablesStrong Weak
You should use Entities (the squares), Relationships (the diamonds) and attributes (the ellipsis). All of them are connected by simple lines.
Finally, and most important. Entities and Relationships are not Tables, as you say. Those are part of a physical model.
In an application I'm writing I have a fairly complicated Database model. I'd like to use EF4 to map this to a whole lot nicer conceptual model. However all the tutorials I've read are with samples of 2 or 3 tables which all map 1 on 1 to the conceptual model.
I'd like to learn how to correctly map the database model to a different conceptual model using VS 2010. However I can't find any good tutorials or (preferabally) instruction video's.
Somebody got any tips, links or even books?
Here are some interesting mapping scenarios.
TPT, TPC, TPH hierarchy mapping
Entity splitting
Multiple entity sets per type.