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.
Related
Quick question about an ER/EER Diagram.
I have made this Entity Relationship Diagram, but I have been told, that there is something wrong with it by a friend. Is there something wrong with it?
The ER diagram is a design of a Library Management System, where a member can borrow 5 books at a time. The rest of the functionality of the system is how a normal library functions.
Library Management System EER
i don't understand the utility of the relationship between the librarian and the card and i don't understand why the books are splitted in two entities.
I would do 3 entities:
-member
-card
-book
every member has one card, every card is of one member;
every member can take many books, every book can be taken by many members,
the relation between member and book create another table in the logic schema: loans. before inserting a new loan you can check if the member has alredy 5 active loans (by checking the attribute active in the loans table).
Your given context is incomplete for me. I do not see the whole description of your problem/situation, so I will answer based on assumptions, and the experience I had during my life. So let's see...
The tino user questioned the existence of two entities, title and volume, which is something important. Let me explain this for a moment, which will eliminate this as an error. Previously (a time ago) we had video rental stores (I don't know if this the right name where you live, english is not my native language). Remember? We used to go there to rent VHS tapes to watch at home.
What we rented were not films, but more copies/midia of them. A film will always have the same actor, director, title, etc., but a copy could have different attributes/properties, like the year that the media was manufactured, the available languages, the expiration year, among other things. So we had distinctly two different things.
But despite this, we have to consider whether there is a need to create two entities for persistence. We have to remember if we need to persist this information. If a copy/midia has no attributes, then it's entity should not exist, and what a user would rent really would be the movies titles.
In your case, the relationship between volume and title, I belive, is really expressing this discrepancy.
Let's talk about the relationship between librarian and title. What a librarian manages? Does It manages the titles that never change and are abstract things, or the physical objects present in the library? :)
Finally, let's talk about the borrows relationship. When we break down 1-N (or N-1) relationships, we always pass the primary key from the 1 side to the N side, solving the relationship to the formation of the Physical Model in a Entity-Relationship Diagram.
Despite this relationship here is a 0-5, to decompose it, we will not have exactly a 0-5 relationship. We would have in anyway to pass the primary key from the two sides to the table formed by this relationship. Therefore, here we have initially a N-N relationship between member and volume.
N-N relationships allow optional relations between entities. This means we can have the zero side cardinality here. To limit the number of books that can be rented, you need to implement a restriction/constraint with SQL, or with any procedural language in your database. In this case, you can implement a before insert trigger. This trigger has a duty to verify this restriction to allow or denny the completion of the operation as a whole.
Let it be clear that I'm not saying you should remove this notation. Your Conceptual Model should express it. But when you are decomposing, you have to remember that. I think you should just correct it.
Remember one important rule: Relations that have attributes/properties (the attributes/properties) can only exist in N-N relationships. If you have to put attributes/properties in a 1-N (or a N-1) relation, they (the attributes/properties) will always be on the N side. In summary, there are no N-1 (or 1-N) relationships with attributes in the relation. Only N-N relations can have attributes/properties. So be careful with this.
Any questions or clarification, please comment and I will answer.
I see no reason to distinguish member and card. Volume and Librarian don't have primary keys. Are they supposed to be weak entities? That doesn't make sense for Librarian and Volume needs an identifier to distinguish different copies.
I have some questions need to be answered. The requirement is to build a database for university entrance system:
"Applicant may apply to 5 university, each university may or may not interview the applicant, then, make an offer to the applicant. The offer may or may not be conditional (conditional/uncondtional), if the offer is conditional, the conditions are stored. The applicant need to choose which conditional offers he/she wishes to accept, up to maximum of 3. If any of the conditions is met when end of the year, the offer becomes unconditional, then, applicant may accept that one."
There are some notable points:
The course work requires using some enhanced ER features such as supertype/subtype.
Regardless the offer is conditional or unconditional, the applicant can accept the offer. Am I right?
In my ERDs, the APPLICATION entity is a weak entity, using a surrogate key, and UNIQUE_CONSTRAINT on University_ID and Applicant_ID.
In my ERD (on working), there are 2 versions. The ERD_1 is a suggestion of my friends. But I think, my work on ERD_2 is more accurate. I have questions:
Am I correct when use a surrogate in the APPLICATION entity? OR using composite of University_ID and Applicant_ID is a primary key?
Could APPLICATION entity be an associate entity? If it is, it could have some subtypes?
In ERD_2, how to show the ACCEPT relationship between APPLICANT and OFFER entity? AND how to show the MAKE relationship between UNIVERSITY and OFFER?
ERD_1
ERD_2
I would appreciate any help.
I can think of no reason why a weak entity could not be analyzed into subtypes (aka subclasses aka specializations). However, your two ERDs suggest that your analysis of your case is not one of specializations. In particular, in your first ERD, you use the word "has" to describe the relationship between an application and an interview or an offer.
"Has-a" relationships are typically not generalization-specialization relationships. "Is-a" relationships typically are. Example: An auto is a vehicle and a truck is a vehicle.
There is an entirely different issue here when it comes to what tables, columns, and constraints you will use to implement your model. That's a design issue rather than an analysis issue.
I don't understand your case well enough to agree or disagree with your analysis of your case.
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.
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.
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.