we sell virtual gift and social experience like hot air balloon rides, tree house, horse riding, Ferrari car riding etc. These experience provides by different suppliers at different address. We are using nopcommerce as our development platform and as we thought our social experiences are products and supplier are manufactures but we still having problem in mapping addresses. The supplier has two kind of address. One the office address of the supplier and second address is where experience will take place. In other words, the products we sell will have many address and also has relationship with manufactures.
The relationship more or less will be
manufactures have many products and one product can be supplied by many manufactures.
manufactures has many address and they also provide experiences(products) at different addresses.
we need product information, supplier information and then address information for each experience(products). The entity relationship is
Is this diagram ok? Or what will be the way to map this information in nopcommerce?
You can use specification attributes in nopCommerce for the providing different addresses of the product.
Related
I'm trying to better understand designing a database schema. After reviewing the solution for a problem that I'm working on, I don't understand why the solution chooses to use an aggregation for the attributes "address" and "phone number" for a given "musician". Here are the specifications, I'm only interested in bullet point 1:
Each musician that records at Notown has an SSN, a name, an address, and a phone
number. Poorly paid musicians often share the same address, and no address has more
than one phone.
Each instrument used in songs recorded at Notown has a name (e.g., guitar, synthesizer,
flute) and a musical key (e.g., C, B-flat, E-flat).
Each album recorded on the Notown label has a title, a copyright date, a format (e.g.,
CD or MC), and an album identifier.
Each song recorded at Notown has a title and an author.
Each musician may play several instruments, and a given instrument may be played by
several musicians.
Each album has a number of songs on it, but no song may appear on more than one
album.
Each song is performed by one or more musicians, and a musician may perform a number
of songs.
Each album has exactly one musician who acts as its producer. A musician may produce several albums, of course.
Here is a solution that I found:
The ER Diagram I created looks almost exactly the same, except for the fact that I made "address" and "phone number" attributes of "musician" instead of giving each of them an entity set of their own, creating a relationship, and turning it into an aggregation. I don't understand why this would be done in this situation. Can anyone explain?? Thank you!
I'm not able to see the image you linked to, but anyway...
no address has more than one phone
This means we should make the phone number an attribute of the address - unless we want to allow for multiple phones per address in the future.
So it would not be completely wrong to make phones a table. But then, we know little about the future. Would there be multiple musicians sharing the same address and the same phones? (I.e. the phone number would be linked to an address.) Or would there be multiple musicians sharing the same address, but each would have their own phone? (I.e. the phone number would be linked to a musician. To use a phone table and link the phones to musicians, however, would only be necessary if a musician could have multiple phone numbers. Otherwise we'd still not make a phone table, but rather make the phone a musician's attribute.)
poorly paid musicians often share the same address
This means we make the address a table of its own. Thus there is only one row to change in case the phone number or some other attribute changes. If we made the address number a musician's attribute instead, we'd store the address redundantly and could get inconsistent data (e.g. same address, but different phone numbers).
A possible data model:
address (address_id, street, city, phone, ...)
musician (musician_id, ssn, name, address_id, ...)
This is a 1:n relation. A musician has one address; an address can belong to multiple musicians.
The primary purpose of database normalization is to make it more difficult for anomalous data to get into the database. Reading the first bullet point, we see that each address may have zero or one phone numbers associated with it. In other words, the phone number is an attribute of/identified by the address. Which normalization level does this violate?
To illustrate how not normalizing the address fields (including phone number) increases the chances of anomalous data, let's say you have four students staying at that address. This means you have four rows where the address data exists. Suppose the phone number changes. You have to make sure you change all four versions of the data. I said there were four students, but suppose there are actually five and I just missed one? Or suppose you found only three when you went to make the change? An address may have at most one phone number however now you have several copies of the same address but with different phone numbers. This is anomalous data.
If this data is normalized, you would have only one copy to change. Since this data is referenced by all the students who live there, no matter how many, this change is "propagated" to all of them. The integrity of the data is maintained.
I have been given the following scenario :
HyperAV is a retailer of home cinema equipment. They sell a variety of products including televisions, speakers, amplifiers, Blu-ray/DVD players and cables. The company has its head office in Stockport and 5 retail branches around the UK (in London, York, Cardiff, Manchester and Newcastle) and a large warehouse in Birmingham.
Due to the specialised nature of the products most sales are made in the shops which also have demonstration facilities allowing staff to show off the products to customers before they buy. However, the shops can also take orders over the telephone. The company deals with a number of suppliers who deliver items to both the shops and the warehouse. Limited space is available in the shops, so large numbers of items are stored at the warehouse and sent to the shops when their stock runs low.
The company’s buyer and stock controller are based in Stockport and work together to ensure that each branch has an adequate stock level of fast-selling items. If a shop takes an order for a product that it does not hold in stock, payment is taken and the item is sent to the shop from the warehouse. If the warehouse does not have a product in stock, it is ordered from the supplier by the buyer.
From this scenario I have been asked to draw a use case diagram.
I have received feedback but only to an extent where I have been told it is slightly incorrect. I would like to know if anyone can see what is wrong with it or how i can improve it in anyway?
I will not go and analyze what is right/wrong with your business case, but here are a few remarks:
Do not use Generalization with UCs. Each UC shall be a unique added value the system under consideration (SUC) delivers to the actor. If you have Generalization this means your UC is not unique. E.g. Deliver product: these are two absolutely separate UCs. They use a delivery service. But that's a UC for another SUC (namely the delivery service).
Avoid the use of <<include>>/<<extend>> as they indicate the use of functional analysis. UCs are about synthesis which is the opposite of that.
Use verb-substantive to name your UC. Order for example is not a UC.
Think about the "use" in UC. What is the added value it returns to its actor? If that is not of a real use, it's not UC. Process payment is an administrative task, not a UC. So what is the use behind this?
I was studying a design case in which they discuss how to deal with the design of the database of a system that is already under development. The system is for for managing public parking. The main debate is how to meet the following requirements:
The system shall allow managing information of each parking company.
The data stored is the parking lot's adress (details, province, county, district), name, corporate identification, number of spaces.
The system should handle reports of the revenue generated by each parking.
These reports should allow filtering by province, as the company has several parking by province, some of them located in the same district.
Some people have mentioned that the table ParkingLot must have the colums for province, county and district, and which are characteristic of each parking.
Others say it should not be. I was wondering which was the best way to approach the design of the database in this specific point.
Which boils down to my questions, in this type of cases (because there must be exeptions) where the system is pretty straight forward, does it really matter?
What if these reports should allow filtering by province? As a company could have several parking lots in the same province, some of them located in the same district.
Based on your requirements, you need to decide what to model.
Option 1 - Columns on ParkingLot
If you add columns for province, county and district to the ParkingLot table, then you are modelling that each parking lot has these things.
Your model in this case does not include a master list of districts, county and provinces. You would not be able to validate that the details entered for a particular lot was valid.
Choose this option if you obtain the parking lots from a trusted source or you district, etc. This option doesn't allow you to store any additional information. e.g. if you need to store a "area manager" against a particular region you would have nowhere to store it.
Option 2 - Model Districts, County and Provinces
You could create tables for province, county and district. These would have foreign keys to their parents. In this case you do have a master list (which you need to keep up to date).
Then on each parking lot you have a foreign key to the district (which implies the other columns).
Choose this option if you want to validate district, etc. against a master list. Also choose this if you have extra information to store against district, etc.
I purchase from a manufacturer gift cards (not virtual ones, but real plastic ones), and keep it in my warehouse as serialized inventory, this base product is not salable.
i sell them as another products, that has additional virtual charachteristic (fixed one, that cant be configured by the customer). e.g. i can have 3 diferent products of: 100$, 200$ and 300$, and have the style of the base product in the warehouse. again,all defined as separate product in the catalogue.
I thought of modeling the inventory product as "configurable product" and the dependant product as "configurable product instance", and add the fixed configuration as features of the product. Is this the correct way? i see configurable product example, only when customer is defining configuration (the PC001 sample).
any other way? (maybe variant? though, my understanding it fits only when base product is virtual)
Thanks,
Amit
For gift cards, I prefer use variant products because that's the way that use OFBiz in the demo data and, above all, OFBiz has processes ready for this type of product-with-variants: load balance of the gift card, relate gift card with customer, etc. Check using Gift Card in OFBiz.
Just one consideration, if you sell the gift card as a product itself, not as a "payment method", then you can use both solutions: you can create the parent product as a virtual one and its "childs" as variants (like a shirt with different sizes), or create it as a configurable one (like a PC with several PC components). Just check the different processes that uses OFBiz to "sell" the product depending of this type (variant or configurable), and use the one that suits you. In this case I also prefer use a virtual product with variants, it's easier to manage it.
I have a database of resources with the typical address, email and all that jazz. One resources can be used by one or more counties. The resources are categorized by Education, Health Care and a couple others. A resource will only ever have one category so it cannot be education and health care, for instance. I would like to use the supertype/subtype relationship. Currently, no category (health care, education etc.) do not have any differing attributes. How could I amend my schema to accommodate that?
below is a screen cap of my current schema.
http://imgur.com/fbrFB
The whole point of a supertype/subtype structure is to gather the attributes common to all subtypes together in one table, the supertype, and to isolate the attributes unique to each subtype in separate tables.
If all your subtypes have the same attributes, what's the point?
I think you'll get more benefit from reconsidering how you're going to handle addresses. Anyone who has a PO box for mail is liable to have different ZIP codes for their physical and mailing addresses.