Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am trying to create a food ordering system for my homework. I learnt terminolgy which like aggregation,composition,inheritance etc. But when i trying to build diagram im confusing about how i need to design.
For beginning i created some classes:
User
Customer
Vendor
Restaurant
Food
Order
Order Details
Shipping Info
Shopping Cart
Payment
I linked some of them but it got worse as it continued.
Is there any suggestion how i design this or what my mindset has to be ?
(Note: I don't need any coding. Just diagram drawing.)
You use too much the composition, this kind of relation is very strong, for instance having vendor <*>---restaurant means when the vendor disappears (dies) the restaurant disappears too, which is wrong
In your case the compositions are not even aggregations, for instance the shopping card is not a part of a customer except if it is tattooed on him ;-)
The inheritances between order details and shipping info with order is wrong, A inherits B means A is a B., Note you can have the composition order <*>---- order details supposing the class order details has a sense.
payment method can be used in class-associations between a customer and the restaurant.
You can specify the multiplicities in your relations, and all of them do not bidirectional.
I encourage you to name the classes with an uppercase character at the beginning of each word (OrderDetail etc)
(You have some free UML tools to avoid to use a pencil)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I have 4 class in my diagram. These are appointment, dentist, patient and seat classes.
In any clinic, dentists use the seats right?. My question begins here.
This is part of my diagram.
the dentist is using the chairs while doing the examination, which type of oop connection should I use when the link seat and dentist classes or should I link dentist and seat classes?
should connection be association, aggregation or something like that? Which connection should I use?
Warning you put an unexpected S at the end of Seat, this is very probably not what you wanted.
By seat you probably mean all the resources used by a dentist to operate/examine a patient.
If a dentist always use the same seat and associated instruments and is the alone to use them the association can be between the dentist and the seat, and that link can be an association, but not an aggregation because the dentist is not composed by a seat nor the reverse.
If the seat and associated instruments is not always the same for a given dentist we can link it with the appointment, again through an association, allowing to reserve it for the operation/examination done by the dentist to the patient
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How to Create optimal database design by looking at below invoice of XYZ Ltd. stationary store, also show all possible tables including relationships.
Here's the approach you should take.
Look through the form to figure out what fields should exist.
Determine the relationships between those fields; i.e. do they relate to the same thing (e.g. the invoice, an invoice line, an item, etc) as other fields.
Figure out the relationships between those things (i.e. can an item appear on more than 1 invoice / can an item appear more than once on the same invoice / is there a 1:1 relationship between them?
For each "thing", create a table. That table should have those fields directly associated with that thing defined on it, along with any useful additional fields (e.g. primary key).
For each "thing" create required relationships between its fields and the related tables' fields.
Good luck.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm working on a project and I usually use the person's ID as a primary key to identify the person. But right now I'm working on something much more formal and serious then what I've been working on... (School DB) Is it good practice to use the person's/student's ID card instead of having another field (ID) auto generated/sequence as a PK.
It is a bad idea, for one simple reason: security.
You are better off designing your databases to have internal ids for all entities. The person's id would then be an attribute on the records, rather than a primary key. This allows you, for instance, to encrypt the id (and other sensitive information). If someone gets a hold of a print-out of some data, you don't have to worry that they are seeing personal information.
In the United States, this design is helped by the fact that social security numbers -- the closest thing we have to a national id -- were specifically designed not to be national id numbers. Apart from the issue of fraud, the approximately one billion numbers will run out one day.
I look after a similar student database and we use student ids as PK.
It helps us because students are aware of their IDs and if they have any issues they can come to us and quote their ID for us to resolve the issue. It certainly makes it easier than trudging through a load of John Smiths.
The down side I have found is that we do export data to programs such as excel and alot of the IDs have leading zeros which if you are not careful will be removed.
It is entirely up to you, but in my opinion I would use them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 days ago.
Improve this question
We have a ruby-on-rails platform (w/ postgreSQL db) for people to upload various products to trade. Of course, many of these products listed are the same, while they are described differently by the consumer (either through spelling, case etc.) "lots of duplicates"
For the purposes of analytics and a better UX, we're aiming to create an evolving "master product list", or "whitelist", if you will, that will have users select from an existing list of products they are uploading, OR request to add a new one. We also plan to enrich each product entry with additional information from the web, that would be tied to the "master product".
Here are some methods we're proposing to solve this problem:
A) Take all the "items" listed in the website (~90,000), de-dupe as much as possible by running select "distinct" queries (while maintaining a key-map back to original data by generating an array of item keys from each distinct listing in a group-by.)
THEN
A1) Running this data through mechanical turk, and asking each turk user to list data in a uniform format.
OR
A2) Running each product entry through the Amazon products API and asking the user to identify a match.
or
A3) A better method?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a class called 'Inventory' that has two subclasses, 'Drink' and 'Condiment'. They are a part of a software system being developed for use in a hot drinks vending machine. Note that this isn't really going to be implemented, rather it is a piece of coursework for my Software Engineering class. Anyway, I'm having trouble deciding what stereotype to apply to 'Inventory', as I can see it having aspects of both a control class (managing the drinks and condiments during a transaction), and of an entity class (noting the quantities of each item in its subclasses, but it also is the sole manager of the water water levels, as hot water is common to all drinks dispenses from this machine).
I'm basically looking for some guidance on how to classify this class. Thanks a lot.
You might consider that since you are unsure how to classify it, perhaps you could design separate control and entity classes. First rule of software engineering: if the design feels wrong then it probably is.
Come to think of it, the zeroth rule is: know when to ignore the other rules, especially the ones about stereotypes and design patterns.
I vote for entity class -- Having inventory is not the same as controlling inventory.