I want to create an UML class diagram of a company hierarchy and I want to especially to mention that every employee has a superior in the hierarchy (for exemple every department in a company has chief and a chief is a superior of other employees in the departement ).
I build this diagram but I feel that there is some thing wrong
I would omit every generalization, it leads to hell (imagine simple situation - you have a hospital with doctors and patients. How many instances of one person will you have, if a doctor brakes his ankle and becomes a patient? And now you decide to have a library. A doctor can borrow a book as well as a patient.). Anyway, I would depict your domain as is at the diagram below (with example).
As for you requirement: I want especially to mention that every employee has a superior in the hierarchy. It is not feasible in a real world. So I use 0..1 multiplicity.
According to your description I'd come up with this:
A Department is composed of Employees. A Chief is an Employee and there's exactly one Chief per Department.
There are definitely other ways to model this. Especially the generalization might be done in different ways. This depends on lots of domain details which can't be discussed here. But basically you could start with this approach.
Related
I'm studying for university and I have to learn the difference between "Role-Object Pattern" and "Type-Object Patern" (Purpose and Class diagram).
I don't find any difference between them. I believe the class diagram is the same, but the purpose is different (I think). So, I don't understand this last.
How can I realize which of them I have to use?
I'm confused.
Thanks.
Take these examples for logical mapping of objects.
You have a customer of a bank. Now that customer can be an investor or a borrower. The borrower and the investor have completely different roles, but both are of type customer. This is role based.
On the other hand you have banks. You can have Axis Bank, ICICI Bank etc, with different rates of interest, different credit card options etc. But they all have same functions, just different results for each. This is type based.
The diagram may seem similar, but it's what's common between them that separates them.
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 need a hand with a specific case for creating Data Warehouse schema for University.
I've tried to create a
[schema] http://i.imgur.com/EJPaVgq.jpg but it looks like im going in wrong direction
Case:
University currently has 5 courses – Foundation, Business Computing,
Business, Economics, and Law. It provides education on 5 levels. Each
academic year consist of 2 semesters. We have a number of modules that
belong to courses and some of them are core modules and some are
optional. Some modules are semester long and some are a year-long.
Each module has assessment components that have weights contributed to
the overall mark on the module. Assessments are of different types
like in-class test, coursework, final exam, etc. Students register on
courses starting from Foundation. Students might change the course
over time (e.g. transfer from Business to Business Computing).
University would like to know about: • students registration on
courses and modules and tracking changes to them over time.
• academic progress and performance of students and faculty in
different courses and modules including assessment components
(coursework, in-class test, final exam, etc.).
If possible, please attach schema as a screenshot or whatever. Im newbie to Data Warehouse stuff, so i dont know much about it and have no expirience in creating them.
I will be very grateful for any help that will somehow closer to solving the problem.
Sorry for my english.
Thank you, and have a nice day.
I am sure it would be hybrid snowflake as you have two fact tables here and will have other several dimension tables connected around
Some quick ref on the advantages of both types of schemas.
http://www.diffen.com/difference/Snowflake_Schema_vs_Star_Schema
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
Hi everyone I was working through a databases exercise and came across the following exercise where I have to create a set of data tables from a given case scenario. But I'm having difficulty working out the attributes in bold:
A database is to be designed for a university to monitor students’ progress
throughout their course of study. The students are studying for a degree (such as
BSc, MSc, etc.) within the framework of a modular system. The university provides
a number of modules, each being characterised by its code, title, credit value,
module leader, academic staff and the department they come from. A module is coordinated by a module leader who shares teaching duties with one or more
lecturers. A lecturer may teach (and be a module leader for) more than one module.
Students are free to choose any module they wish but the following rules must be
observed: some modules require pre-requisite modules and some degree
programmes have compulsory modules. The database is also to contain some
information about students including their student numbers, names, addresses,
degrees they study for, and their past performance (i.e., modules taken and
examination results).
So far the tables I have are:
University
ModuleCode, ModuleTitle, CreditValue, Department
Module
ModuleCode, ModuleTitle, LecturerID
Lecturer
LecturerID, ModuleCode, ModuleTitle
Student
StudentID, Name, Address, DegreeCode
Degree
DegreeCode, DegreeType, DegreeTitle
Performance
ModuleCode, ModuleTitle, StudentID, Result
Is there anything that I'm missing out on or can improve?
A few thoughts (in no particular order):
I would have assumed there is a one-to-one relationship between ModuleId and ModuleTitle. That is, that a ModuleId uniquely identifies a ModuleTitle. In that case, you shouldn't be be using both ModuleId and ModuleTitle everywhere you're identifying a module, but use only the uniquely identifying value. (Except in the table where the relationship between ModuleId and ModuleTitle is defined.)
Lecturers can teach multiple modules. Yet, you've include the ModuleId as part of the Lecturers table. See the problem here?
Is the LecturerId in the module table intended to be the moduleLeader? If so, say that. A foreign key doesn't always have to be the same name as the primary -- in general it's a good idea, but you want to clarify that this is a special lecturer. Or perhaps, you want to add a table that specifically identifies which lecturers are module leaders.
I don't see anything here that implements the 'some modules require pre-requisite modules and some degree programmes have compulsory modules' requirements.
In would interpret 'the department they come from' as referring to the academic staff, not to the module itself. It's not clear that a module could only be taught by people from one academic department.
In the real world addresses are much more complicated then just saying address as a field.
The last point is somewhat nit-picky, but the rest should be addressed. I think you've still got some significant work to iron out these issues.
In general, I think you're going to need to break this out into more tables, to represent each of the individual entities (modules, lecturers, departments, and then build tables to define the relationships between them.
On the first pass, I'd read the description like this. (Possible tables in bold, some bolded more than once.)
A database is to be designed for a university to monitor students’
progress throughout their course of study. The students are studying
for a degree (such as BSc, MSc, etc.) within the framework of a
modular system. The university provides a number of modules, each
being characterised by its code, title, credit value, module leader,
academic staff and the department they come from. A module is
coordinated by a module leader who shares teaching duties with one or
more lecturers. A lecturer may teach (and be a module leader for) more
than one module. Students are free to choose any module they wish but
the following rules must be observed: some modules require
pre-requisite modules and some degree programmes have compulsory
modules. The database is also to contain some information about
students including their student numbers, names, addresses, degrees
they study for, and their past performance (i.e., modules taken and
examination results).
Since this is for one university, I probably wouldn't create a table of universities, although I could make a good case either way.