So I need to practice UML for a uni course and I can't figure out the following:
We need to make a UML Class diagram of a sports association. There is a player table. A sub-class of the player table is the referee table. A player is part of a team, and so is a referee (since referees are players also). A referee gets assigned to a match, but it can't be the match of his own team.
I can't find the answer to the last sentence. How do I put this in the UML Class diagram?
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.
Below is a graph of a database to be used to manage university student enrolment and grades across multiple years. Below are the listed requirements for the database
Students must be able to be a part of a class
A class must teach a subject
Each class may have 0 or more courseworks
Each class will have one exam
Each class can be taught by more than one lecturer
Coursework can only be set by one lecturer
Coursework and exams can be marked by different staff than who set them, and the staff member marking it must be able to be identified and recorded.
It is necessary to specify whether an exam taken is being taken for the first time or is a resit
I think the database is now in 4th normal form, and is represented in the table below.
The key represents the primary key for that table, and a green arrow means it is a foreign key.
Can anyone spot any errors or suggest ways to improve it?
Not enough information here to tell whether you are satisfying any Normal Form or not. We can only guess at some dependencies.
For example, "Each class will have one exam" seems to be saying that class→exam. Your Exam table on the other hand satisfies the dependency examID→classID, which is not one of your requirements. I can't tell from your diagram if classID is a candidate key in the Exam table. It also looks like examTaken would not be in 4NF if the classID→examID is one of the dependencies to be satisfied.
From a practical data modelling point of view 4NF is not very important. 5NF is more important. Is this homework? If so I'd suggest you write down the attributes and dependencies before you start drawing a diagram. You seem to have created far more attributes than are suggested by the statement of requirements.
Obviously the cardinality between coursework and courseworktaken cannot be 1:1.
(Why are some lines dotted and others not ?)
I'm a bit confused at how to translate the Official entity in my ER diagram. I know for a 1:N relationship, the 1 side of the relationship becomes a foreign key in the N side of the relationship.
So for the relationship: Game - Head Officiated - Official, the primary key (game ID) should be a foreign key in the entity Official? Here's what I currently have and the entity Official doesn't look right.
Official (OfficialID, Fname, LName, Home City, GameID*??)
Game (GameID, Date, City, Head Official*)
My ER diagram
I'm beginning to doubt if my ER diagram is correct as well. Here's is a description of the database (I omitted the parts that are not relevant to the question:
For the officials, you must keep track of their first and last names (each will be 20 letters) and their official id (a 2 digit field) and their home city (15 letter field).
For games, you must keep track of the game id (2 digits), the date of the game and the city the game took place in (15 letters field).
Games are officiated by officials (refs). Every game has at least one official, but may have more. Every game has one official who acts as the head official (so every game will at least 2 officials, a regular one and a head one, HINT: keep track of both (officiates game and head officiates game) as 2 separate relationships). Some officials will be in our database who have not yet officiated any games.
EDIT: min,max notation messed me up. I get it now, sorry if I confused anyone.
I am having some trouble getting my head around cardinality in ER diagramming. I am linking an example I found to help me explain where I am getting confused.
http://www.postgresqltutorial.com/download/dvd-rental-er-diagram/#
Question 1:
The cardinality between Customer and Rental is 0:1. So that means a customer can take out zero or one rentals. I would have thought the customer would be able to take out 1 or many rentals (1:*) because a customer means that they are taking out a rental (can't be a customer if you are not spending any money) and that a customer could take out many rentals.
Question 2:
Also for the Staff to Payment relationship. Staff to Payment is 0:1 cardinality. I would have thought that a staff would make at least one payment because payments are necessary for the rental transaction. And then in reverse (one payment can be made by one and only payment): just to clarify this is because logically a payment is a transaction that only be made by one person at a time?
I agree with you. The same thing occurs on both sides of film_category, which I believe represents a many-to-many relationship based on the primary key. I think the diagram was drawn incorrectly.
Note that there's no such thing as 0:1 cardinality, but rather 0/1:1. Also, despite what the site and diagram says, the diagram is a table diagram and not an ER diagram. The notation used doesn't support or distinguish all the concepts from the Entity-Relationship model. Proper ER diagrams use Chen's notation or something equivalent.
My assignment is to draw an ER model (by hand) using Chen notation using the specifications below:
http://i57.tinypic.com/73ff2f.png
If you have questions about these specs. I'll play the role of the
client who will resolve them.
The database will serve a university.
Students have id's, names and gpa's. They must have exactly one major,
but they could have minors as well. Each major or minor is a
department which has a unique name and a phone number. For each
student with a minor, we record the date she signed up for it. Faculty
members are associated with a unique department and have id's, names
and office locations. Each internship is held by a particular student
at a particular compain and is supervised by a particular faculty
member. We also keep track of the last term in which that student
registered under that advisor for an internship at that company.
Students may have many internships over time. A given faculty member
may supervise many students at a given company, and she may supervise
a given student at several companies. However, for a given student and
company, there can be only one faculty advisor.
Students, Departments,
Faculty and Companies should be your entity types. Internship should
be a ternary relationship type. The specs should also lead you to some
binary relationship types. Don't add any ingredients to this mix other
than what appear in the specs.
Below is my work:
http://i60.tinypic.com/28rf7tf.jpg
Can anyone please help as I really need a better understanding of this (my professor is AWFUL at explaining this).
You missed (per your assignment's last paragraph) a department entity type. (Box.)
You missed 'Faculty members are associated with a unique department'. That's a relationship between those two entity types. (Diamond with lines to those boxes.)
You could have those major and minor entitie types that are 1:1 with departments. (Your present boxes with each a line to its own diamond each with a line to department.) But (per your assignment's last paragraph not listing them as entities) you could have major being a relationship 'student[s] has a major in department [d]' and similarly for minor. (Lines from student to each of two diamonds each with a line to department.) But the assignment actually says 'each major or minor is a department' so that's major as 'student[s] has major department [d]' and similarly for minor. (Same picture.)
Per your assignment's last paragraph you should make internship a ternary relationship. (Under Chen it's a relationship diamond (possibly with its own properties) formed by 3 lines to entity type rectangles (possibly with their own properties) rather than an entity box.) However, it's not clear exactly when your assignment considers that an internship holds. (It tells us what relationships hold; it's just not clear which one it wants to call interning.) (Although we can look for interpretations consistent with it being ternary.) One is 'student [s] interns at company [c] supervised by faculty member [f]'. But since 'for a given student and company, there can be only one faculty advisor' that notion of internship is more simply characterized by a binary relationship 'student [s] interns at company [c]'. But then you still need a relationship 'faculty member [f] advises student [s] at a company [c]'. So I will suggest that your assignment expects the former. We can add property term. (This is more reasonably called a relationship on student, company, faculty member and date; but E-RM considers relationships to be on entities. Although it all depends on your class's method's particulars.)
(The possibility of multiple reasonable variations is why you should propose a particular design fully handling a particular specification in a SO question.)
A problem with the E-R Model [sic] is that it introduces needless distinctions between entities, reltionships and properties. There is really no distinction between a relationship instance and an entity. Eg: Here we could just as well have an internship be per above an entity in a 4-way relationship plus property. Eg: Your assignment says 'each major or minor is a department'. But a major or minor isn't a department. A major or minor could be considered a subject, which would be the subject after which a department is named or the subject of the degree offered by a department. Or we could just have relationships in which a department participates but the relationship is about that department's subject or name or degree being a major or minor.
(If an internship as relationship participated in its own relationships I don't know how your instructor's particular method would keep the further lines organized. Some methods add internship entities (box) 1:1 with relationships (diamond); then some methods specially associate the entity type with the relationship as a reification while some make the relationship 4-way by including the reified entity type. Eg 'internship [i] is student [s] at company [c] and ...'.)
(Correctly speaking there are entity types vs relationships and entities vs relationship instances. But the assignment talks of relationship "types".)
Re E-RM see this answer and this one. Also the E-RM wiki page section 'Entity–relationship modeling'. (Which correctly mentions misinterpretations of Chen's E-RM & E-RDs by some related modeling and diagramming methods and tools and even some presentations of E-RM itself. But the 'Overview' is nonsense.)
Re E-RM problems see this.