I have a confusion in UML class diagram Multiplicity.
To ask my question , first i need to give you an example of a situation; Consider this requirement:
"Sections shall have many topics."
I can make the classes for Section and Topic with their multiplicity as follows :
Example 1)
The above relation can be read as : "One or more sections has many topics".
But consider this design also :
Example 2)
The above relation can be read as "One section has many topics , and one topic is in only one section."
Question 1 is :
What is the correct design?
Because for me i think the Example 2 design is the correct one, because i am considering only ONE instance at that particular time. But in Example 1 , they considered the Section class as a very high view! (Of course i can make infinity number of instances of any class...)
Question 2 is : In Example 2, do we say that there exists only one Section in the whole system, that's why we write it as in Example 1? Also in Example 1, This relation is Many to Many, so we need to make an association class to handle it.
I hope you understood my confusion, thanks in advance :D
Q1: In fact it depends on the requirements. A Topic can appear in many Sections as being discussed under different aspects. If you require that a topic must be completely covered in one section then your 2nd approach would be right. Anyhow, I think that the first is the more common way of doing things.
Q2: No. You only say that a Topic can have only one Section. To tell that there's only one section allowed you'd probably need a constraint. (I used a <<singleton>> stereotype for such purposes which is no UML standard, though.)
BTW: you multiplicity in ex. 2 is wrong. To the left you must only have 1..* and to the right only one 1.
In example 1 there are two independent statements:
Every instance of a section can have any number of topics and
every instance of a topic must have at least one section. I don‘t know whether this is what you meant.
PS: The composition, shown by the filled diamond, implies exclusivity. Therefore, the multiplicity can at maximum be 1, not 1..*.
An Association Class is not needed. Many to many relationships are just normal Associations.
Related
pretty much noob here. What is the difference between these two schema for shopping website.
Normally I use this schema.
I saw this one here (https://github.com/ramortegui/e-commerce-db)
Should I keep using the first one or change to second. Is there any advantages?
In example 1 every product can have only one category.
Example 2 allows multiple categories per product.
To provide you better understanding,
Some of the Users in my database will also be Practitioners.
This could be represented by either:
an is_practitioner flag in the User table
a separate Practitioner table with a user_id column
It isn't clear to me which approach is better.
Advantages of flag:
fewer tables
only one id per user (hence no possibility of confusion, and also no confusion in which id to use in other tables)
flexibility (I don't have to decide whether fields are Practitioner-only or not)
possible speed advantage for finding User-level information for a practitioner (e.g. e-mail address)
Advantages of new table:
no nulls in the User table
clearer as to what information pertains to practitioners only
speed advantage for finding practitioners
In my case specifically, at the moment, practitioner-related information is generally one-to-many (such as the locations they can work in, or the shifts they can work, etc). I would not be at all surprised if it turns I need to store simple attributes for practitioners (i.e., one-to-one).
Questions
Are there any other considerations?
Is either approach superior?
You might want to consider the fact that, someone who is a practitioner today, is something else tomorrow. (And, by that I don't mean, not being a practitioner). Say, a consultant, an author or whatever are the variants in your subject domain, and you might want to keep track of his latest status in the Users table. So it might make sense to have a ProfType field, (Type of Professional practice) or equivalent. This way, you have all the advantages of having a flag, you could keep it as a string field and leave it as a blank string, or fill it with other Prof.Type codes as your requirements grow.
You mention, having a new table, has the advantage for finding practitioners. No, you are better off with a WHERE clause on the users table for that.
Your last paragraph(one-to-many), however, may tilt the whole choice in favour of a separate table. You might also want to consider, likely number of records, likely growth, criticality of complicated queries etc.
I tried to draw two scenarios, with some notes inside the image. It's really only a draft just to help you to "see" the various entities. May be you already done something like it: in this case do not consider my answer please. As Whirl stated in his last paragraph, you should consider other things too.
Personally I would go for a separate table - as long as you can already identify some extra data that make sense only for a Practitioner (e.g.: full professional title, University, Hospital or any other Entity the Practitioner is associated with).
So in case in the future you discover more data that make sense only for the Practitioner and/or identify another distinct "subtype" of User (e.g. Intern) you can just add fields to the Practitioner subtable, or a new Table for the Intern.
It might be advantageous to use a User Type field as suggested by #Whirl Mind above.
I think that this is just one example of having to identify different type of Objects in your DB, and for that I refer to one of my previous answers here: Designing SQL database to represent OO class hierarchy
I ask this because I seem to lose information when I remove one the FDs and convert the relation to 3NF.
If you have a relation with two attributes R(A,B) and the two dependencies {A→B, B→A}, then the dependencies are already a minimal cover, and you cannot remove one of them.
Note that in this case the relation is already in Boyce-Codd Normal Form and in Third Normal Form, and A and B are both candidate keys.
While studying for Interviews, this question came to my mind.
I am planning to design a parking lot and I am assuming the following things:
It has multiple levels. Each Level has 2 rows.
The vehicle type could be small, compact and large.
Each row at a certain level has multiple parking spots.
Each parking spot has red/green light indicator( Red- No space, Green- Free space)
Also each parking spot will have size small, compact and large.
6(optional). Also want to add handicapped person situation.
These are some of the assumptions that I could come up with(Not sure if they are enough or I need more).
I was thinking of designing the system in such a way that as soon as the Vehicle enters the Parking entrance.
He should be given information that where is the nearest vacant spot available(For example- Level 3, Row 2, Spot # 10)
I would like to know how to go about designing such a system? I have seen many other designs but none achieves this i guess.
Not sure what you want to achieve through point 6, but the rest are pretty simple to achieve with an OO design, through the usual abstraction, inheritance and polymorphism principles.
You can have an interface called AvailabilityIndicator which has a boolean method isAvailable(), which represents the light indicator (the bulb will show red if isAvailable() is false, and green if true).
You can have an abstract class called ParkingSlot, which implements AvailabilityIndicator.
This could have the level, row and spot number in it.
You can have 3 classes LargeParkingSlot, CompactParkingSlot and SmallParkingSlot which extend ParkingSlot. (Not that your functionality actually needs this, unless the different parking slots have different behaviours or data you want to model, but since you mentioned you wanted an OO approach I mentioned it, otherwise a simple slotType parameter in ParkingSlot would do.)
Then its a question of when the vehicle arrives, checking what type of slot it needs and looking up which are the available ones that match. You might want to put them in a Map data structure which maps each slot type to the list of available ones, so that when one is taken it is removed and put in a separate unavailable list, for fast lookup of available slots when a vehicle arrives.
I am currently coursing Computer Engineering and I remember a professor of a class called Introduction to Informational Systems saying that two classes related by a 1:1 cardinality does not make sense.
For example: I have the Client class and the Telephone class. Let's supose that the client can only have one phone. The professor said that does not make sense creating the Telephone class, and telephone should be an attribute of the Client class. I absolutely agree with him.
But now I'm taking the Software Engineering class and the professor (not the same) did not make any comments about this issue, and now I'm really confused about this.
What is the correct approach?
I would say your Introduction to Information Systems professor was correct. And your SE professor, too (assuming his lack of comments makes him a contrarian). They are each right depending on your requirements and the domain you're working with. But without any other details, it's hard to model this for you, and I would lean towards what your CE professor had said. Keep in mind all those fun little principles you learned: KISS, DRY, etc., and apply them to your problem.
If Client will never ever possibly have more than one telephone number and no other entity in your domain needs a telephone number, then a separate Telephone class isn't necessary. In the real world, if your requirements are vague, find out more information from your client.
If somebody down the road decides Clients can take on more than one telephone number, or another entity is introduced into your domain that needs a telephone number, this is a fairly easy refactoring to accomplish.
So with that in mind, let's say your Client had a separate Address class that included the telephone number instead. Maybe that Address class gets re-used by another class, maybe Invoice or Shipment, where an Address could be shared or applied in both cases. In this example, you might want Address (Telephone) to be its own class.
In your example, Telephone might be a little too contrived. You'd want it to be a separate class for re-use if it had many properties (AreaCode, InternationalPrefix, Number, etc.), but if Client just needed a string-value called Telephone that a user would be typing in merely for reference, then it probably doesn't make sense to be its own class.
If you wish to re-use the Telephone class, it won't be very useful having it as a part of the Client class. That would be one really good reason. If you leave it in the Client class, it implies that it is intrinsically part of the Client even when you use it elsewhere, which I doubt you would ever mean.
Sometimes though, it makes sense to model 2 entities with a 1:1 relationship as separate classes. Perhaps you have a Client and you also have ClientBilling. You do not want all of your programmers to have access to the ClientBilling so you move it into its own class where it can be separately controlled.
Perhaps your structure is huge, and shipping the whole thing around isn't normally necessary. By breaking it into functional pieces, you can reduce the size of the data to only that needed for a particular function.
Perhaps the 1:1ness isn't necessarily intrinsic to the data and a reasonable guess would be that it will not always be that way. Tour Telephone example falls into this category I think.
I'd say 1:1 relationships (mandatory on both ends) are suspicious and should be carefully considered to be sure they are needed. Usually it's a trade-off between flexibility and simplicity of the diagram (flexibility because it will be easier to change the diagram in the future and adapt it to new requirements if you keep the two classes against simplicity of having to maintain one class instead of two)