Here I have a Movie entity with all the attributes I need. What I am having trouble understanding is what if the DVD store has more than one copy and more than one format of each movie. For example, each copy of these movies is identified with the combination of Movie_ID and item copy number. So what I mean is when a customer rents a Movie Item, he/she actually rents a copy of the Movie - called an item. Example: "Batman" is a Movie...but your DVD copy at home is an Item. So what gets me lost is a customer can rent copies of the same of different Movie Items according to his/her quota. Is this ok what I did ? If not, what is one of the ways to do it ?
Movie item represents the copy of the movie right? the actual disk itself?
Lets rename it for now so i can explain better of course you can rename it to your liking.
Lets call it ProductInformation for now.
so you have a productinformation which in this case is linked to a movie. the ProductInformation needs to have an extra value however it needs to know if its a DVD Blue-Ray or something else.
So we will create another entity called ProductType. this should contain an ID and a TypeName which will contain the values DVD, Blue-Ray or something else.
Create a One to Many relationship between ProductType and ProductInformation.
There, now we have a productInformation with a type and a movie linked to it!
Add CurrentPrice and IsRental columns to this entity remove the price and isrental property from the movie entity.
You should change the relationship between productInformation and Movie as so:
One movie can have many ProductInformation, one ProductInformation can have only one Movie.
Now lets make a Product Entity. The product Entity will represent the actual product (the physical DVD, Blue-Ray or something else).
It will have an ID, maybe a barcode if applicable since it is a store.
Lets create a relationship between the ProductInformation and Product, one product can have one productInformation, one productInformation can have many products.
Now Remove the relationships you've had between your user (rename user to customer) and movie. movie is not physical, the customer will not rent a movie, it will rent a product. movie is nothing more but information about the product.
Now we need to create an entity ProductCustomer or maybe name it Transaction.
This will take care of our many to many relationship between users and products.
Give it an Id, ProductId, CustomerId, Price (Hey we added that at our ProductInformation didnt we?!, Yes we did, but prices change. the transaction will be in the database forever. so for bookkeeping purposes we need to give it a Price aswell, so that we know how much a customer had paid at that time.) move the properties rentaldate and returndate from movie to this entity (productcustomer or transaction), and remove them at movie. aaaand you should have everything fixed, all your worries should be resolved.
Sorry i cant draw a diagram for you, only just got this laptop. :-)
Hope my explanation says as much as a diagram would.
Hop the draft model helps you:
Related
I am trying to build restaurant system.
First I am building ER diagram for the requirements.
I have two tables, customer, it has only attribute which is table_number, and
another table is Item, which is the dishes that the customer will choose from, and it has several attributes which are (id,name,category,price).
A part of requirements which I faced problem with it is :
when customer make the order and submit it, two things should be happened, first send the order details to the kitchen and then save the same order in history_order.
My question is :
how can i represent tow many-to-many relationship between these tables
I know how to represent the current order that will read it by chef, but i do not know
how to represent to kind of many-to-many relationship in the best way without break
the principles or best practices.
I downloaded my work in image to show you what i am talking about.
I hope it is clear and understandable.
If there is anything unclear, please just let me know by the comments.
the ERD diagram
The order is the order. It's sent to the kitchen, and it's archived in the history. Like everything else, you want to record it once. Possibly you'll refer to it from more than one table.
Let's say you have a table order_items with key attributes order_id and item_id. Now you can look up all items for an order. You could have another table to track the progress of each order. Call it orders with attributes order_id and status, which might have values such as ordered (sent to kitchen), ready (to be served), served, perhaps cancelled, and (hopefully) paid. You could also have an attribute status_time to record when the status was last updated. Your list of orders "in the kitchen" are those orders with status ordered; the history is those with status paid.
You probably don't need an order_id. From your description, it looks like table_number and order_time uniquely identify each order. You could use that pair instead of an opaque ID.
We are trying to implement a University system for students, faculty, and staff to be able to better manage course registrations as well as other enrollment activities.
Consider the following problem: When a student registers for a course, the course needs to get added to the students bill as a billing line item. The bill needs to have a total price of all the courses that have been registered for that particular student. Note: We've tried to keep the process manual in order to simplify the requirements.
We have identified 4 custom objects and some important fields:
Courses - Course Name:(Primary Key), Course Size:(Number), Course Price:(Currency), Start Date:(Date), End Date:(Date), Students Enrolled:(Rollup Count)
Course Registrations - Course Registration Number:(Primary Key), Course List:(Master-Detail), Student:(Lookup), Course Price:(Formula), Course Credits:(Formula)
Billing Line Item - Billing Line Item Number:(Primary Key), Course Registration:(Master-Detail), Bill:(Master-Detail), Course Price:(Formula)
Bill - Bill Name:(Primary Key), Student:(Lookup)
We know in order to summarize the total of all course prices, we need to make the Billing Line Item the detail object and the Bill the master object. We want to perform a Rollup Summary on all the Billing Line Item prices.
We've also made the Billing Line Item the detail object and the Course Registration a master object. This is because without a Course Registration, there is no need for a Billing Line Item to exist. Also the Course Registration has the Course Price via a formula which needs to be used in order to summarize the total cost of all courses.
I've seen online that you are unable to summarize a cross-reference object. We are getting confused as to how we should summarize all the prices associated with each course. Any help would be greatly appreciated. We can provide screenshots if requested!
I don't think the reference to course price should be a formula. Next year you'll change prices and it'll retroactively screw your past invoices up? (and you wouldn't even have field history tracking on the formula field, only on the Course. So if you don't know where to look it'll be as if it always was this price)
Make it a normal editable Number field (although Currency type would be better) and use workflow / "early" flow / process builder or code to populate the list price on save. You don't lose anything (as you create new line item now you also don't see the price until you save, formula field doesn't show up on "new", right?). This normal field will already be rollup-able but you can spice things up by adding discount % or differentiate between list price, sales price... Look how much stuff is on built-in OpportunityLineItem
If you feel really fancy - you can include something that on change of Course's list price would cascade down to all registrations and billing items where status = Open(?) and update the list price...
I have been studying datawarehouse in the last couple days, particularly, i have been reading The Data Wharehouse Toolkit - The Definitive Guide to Dimensional Modeling by Kimball and Ross.
Uppon that reading, i came to the 1st exapmle where there is a sales fact and it related to a product dimension, as you can see in the bellow image:
I think i can grasp the gist of how this relationship allows us to rotate the "cube" slicing and dicing data, however this is where i get lost:
In this example and many others on the web product is a one-to-one relationship with sales, which is fine i guess for most cases. But this generates a sales registtry for at least each kind of product that was in one sale.
So supposing i bought 1 banana, 2 apples and 1 orange, this would yield at least 3 sales registry. Again, which is fine i guess as it is storing the sale's ticket ID in the sales fact, we still can relate all itens in a given sale.
However if this was an use case: relate products on sales say i want to get every sale that had a banana and get stuff like: how many items each of these sales had, their price cost, their profit, stuff like that...
Wouldn't be better if the fact-product relation were Fact-one_to_many-Product relationship? Where fact would hold the sale's ticket ID and products would have its foreign key referencing where they are from or something?
I reckon these metrics should be in the fact table, and not in the product table as i think i would want. So, is this me not fighting my urge to normalize it or does it make sense in the way i would want to do that kind of filtering -> [given all sales with X product, get data from other products in the same sale].
If i were to follow the guidelines, product dimension would have one registry for every exclusive kind of product the store would have correct? And all the measurements i want i would store it on the fact itself, like price cost, sales price, profit, etc...
On the other hand, if i were to one-to-many product dimension would have many copies of each product. Which is bad, i think. However, i think it would give me better queries in that regard.
As you can see, i'm a beginer and really in the early stages of this path, so if you would endulge me in a Explain Like I'm Five kind of answer I would appreciate.
EDITED:
Sorry #Nick.McDermaid, you are right. I meant from the perspective of the sales fact where for every sale fact i will have only one product, but are correct that for one product it can have N sales related. And so, we have one record of product in the database for every different product on our store. This is the right way to do it, how to rightfully model it. Also, the many indicator is the "sales quantity" i'm guessing.
Anyhow, while this allows for slicing and dicing when/if we have sales as the point of view, but what if i want to for example:
Get all sales that had a banana in it, with all the other items in those sales. We can still do it with this structure but its harder than if the products were repeated and we had the sale id as a foreign key in the product table.
Cuz ultimetly i want to get all the sales(and products within that sale) that had a banana. And then take metrics out of them.
What you are somewhat hinting at would be a degenerate dimension, consisting of the sales id/invoice #/purchase order # of the transaction that took place. The whole purpose of a degenerate dimension is to group items that are related by a meaningless piece of data. For example, a PO # of A1234 is meaningless on its own, it doesn't tell you anything about the purchase. However, it can be used to identify other meaningful data, such as the date of purchase of the products for the customer. In that context, the PO # is defined by the collection of the entities it brings together to describe an event.
Another critical concept in data-warehousing is the abstraction of the schema in the database from the model in the cube. You don't join and group data in a cube model. You slice and filter. There are no foreign keys in a cube model. Those are used in the underlying data schema, but all of that work is handled behind the scenes of the cube model.
I will try my best to phrase this in a way that makes sense. I am working on a database project for my beginning database management course that uses a fictional scenario of a bookstore owner who wants me to create a database for them.
Essentially, the tables (or entities) that I have come up with are as follows:
Customer,
Product,
Order,
orderLine,
Book,
Author,
Publisher
To put it simply, I need configure this so that I can track both books and other nonbook items from sales. The issue that I am running into with this is that when I tried to just have one products table, I ran into the issue that books have a bunch of attributes that other items (such as bakery items). If I put books with other items, then there would be a whole lot of empty cells where there is no author/publisher/genre. From what my textbook has taught me so far, a composite table is needed for an orderDetail-type table, where the orderNumber and productNumber would combine. But here, I would need to somehow combine two seperate KEY attributes (for books and other items) into one order table, or some other method. This is especially confusing to me since some customers might buy a combination of books an other items in a single order, or they might only buy one type of thing. I was thinking that the ISBN would be an excellent identifier key for the Book table. What kind of configuration would I need to track orders like this?
Add one more table , product-props and store attributes in that table. you can keep all products in one table i.e books and other items as well. you can move author, publisher as props of this as well
I'm currently developing a small customer relationship and invoice management system for my client. And I have run into some small issues which I would like do discuss.
What is the best practice around orders, customers and products. Should my client be able to delete orders, customers and products?
Currently I have designed my database around the principle of relationships between order, customer and product like this:
Customer
ID
Name
...
Product
ID
Name
Price
...
Order
ID
CustomerID
OrderDate
...
Order Line
ID
OrderID
ProductID
Like this I can connect all the different tables. But what if my client delete a product, what happens when he later open a order he created months ago which had that item in it. It would be gone, since it has been deleted. Same goes for customer.
Should I just disable the products and customers when the delete button is clicked or what is the best practice?
If I lets say diable a product whenever my client decides to delete it, what happens then if he later tries to add a new product with the same product ID as a disabled product, should I just enable that item again?
Please share your wisdom :D
"If I lets say diable a product whenever my client decides to delete it, what happens then if he later tries to add a new product with the same product ID as a disabled product, should I just enable that item again?"
Depends entirely on your business scenario - what is unique in the way customers maintain it currently? (say manually?) How do they handle when an old product which was earlier discontinued suddenly reappears? (Do they treat it as a new product or start referring to the old product?) I guess there are no right or wrong answers to these questions, it depends on the functionality - it is always advisable to understand the existing processes (minus the software) already followed by the customers and then map them to the software functionality.
For eg. you could always add a 'A product with this code already exists - do you want to use that instead of creating a new one?' kind of a message. Also, the product ids that you use in your tables as foreign keys, and the ones that you use to show the customer, better be different - you dont want to get them mixed up.
Why would you want to be able to delete orders? I would think that such a system would lock orders so that you know you have a good history. Same goes for customers, why delete them? Perhaps a way to "archive" them, having to set some flag, that way they don't show up on customer lists or something.
As for disabling and then entering a new item with the same product ID - I'm not sure why you'd do that either, each product ID is unique for a reason, even if you discontinue a product, it should keep it's product ID so you have a record. But if you must, then you could put a constraint in the business rules, something to the effect of "If there is no product that is active with this product ID then allow it. If we have a product that is active and it has the same product ID, then throw an error." Thus, you only allow for one active product with that product ID - but honestly, I think this would be confusing, and on the back end you'll want to use a unique id that is unchanging for each product to link between tables.
Instead of "deleting" I would add a boolean column for IsActive. That way you won't loose historical data. For instance, if they are able to delete a customer then they won't be able to look at history regarding that customer and it may make looking at statistical data hard or impossible. For the order table you could have a column that represents something like "current", "canceled", "filled" to accomplish the same thing. That column should be a code to a lookup/codetable.