I have so far 5 tables:
Customers (name, type of basket, frequency...)
Basket_junction (delivered, paid...)
Basket (year, week, odd or even, type of basket...)
Basket_details (product name, quantity...)
Products (name, price...)
(I didn't put on purpose the primary keys and numerous autonumbered IDs)
I would like to be able in a form to create a basket that can be applied to a list of customers depending on their type of basket (subscription) and frequency.
For example, I create on week S2 a P12 basket containing a certain amount of products in a form. And i want this basket attached to all of the customers who have the "P12" subscription on even weeks. I want then to be able to say for each customer if the basket has been delivered and paid.
I am pretty new to this.
Related
I want to create a database following the following specifications:
A well known bicycle company stores its data in a special database.
Company has customers and
products.
All customers have a unique customer_id.
Customers are categorized as foreign customers or domestic customers. A customer must
be foreign or domestic, and can not belong to both of the categories at the same time.
Foreign customers are identified by their unique id, currency, company name and address
composed of city state and zipcode.
Domestic customers are identified by their unique id, name and address. Domestic
customers may have more than one address information.
Products are identified by unique product_id, model, type and price.
Only two type of products are produced in this company. These product types are Bike and
Mountain Bike.
Each bike has color and cycle attributes.
Each mountain bike has cycling team attribute.
A product may belong to at least one of this types. Moreover it may belong to both of them
at the same time.
Customers may request products. And a product may be requested by more than one
customer, also it may not be requested by any customer at all.
When a product is requested or ordered by a customer; request id, request type and request
content information is stored.
I asked about the composite key address and I got 2 possible choices right now: Create a table for address or create city, state and zipcode keys and add a constraint named address. However, it says that a domestic customer may have more than one address information. I don't know how to do that.
I have a system that lets members rent equipment and the system should have a history of each item that was rented and by who. The system should also track who has what equipment rented/checked out and should also sort the equipment by type, status, name, etc. Lastly it should also send out notification email on equipment that are overdue.
I'm trying to understand the relationships and how I should model this. As of now my current tables and thinking is something like this:
Member Table:
Id (PK)
MemberId
FirstName
LastName
Email
EquipmentItem Table:
Id (PK)
EquipmentName
EquipmentType (FK)
EquipmentStatus (FK)
TotalQuantity
RemainingQuantity
EquipmentStatus Table:
Id (PK)
StatusName
EquipmentType Table:
Id (PK)
TypeName
EquipmentRentalHistory Table:
Id (PK)
MemberId (FK)
EquipmentId (FK)
CheckOutDate
ReturnedDate
1) I want to know the relationships between these would the rental history be a many to many relationship between the Member table and EquipmentItem table?
2) Would EquipmentItem table have a one to many relationship between the status and type, the way I see it is EquipmentItems can have many statuses or types but each status or each type can only belong to one EquipmentItem.
3) Does it make sense to have a quantity field in the EquipmentItem, I used to work in a grocery store so I'm basing the logic on barcodes where same products would usually have the same barcode e.g. (Cheetos Puff chips) all Cheetos Puff chips would have the same barcode but would have a quantity value on it. Or would it be better to have each item unique regardless if it's the same product/model?
My logic would be:
member rents out item
system logs it into the history table
system then checks how many of the same item has been checked out so far, if say we have total quantity of 4 on that item and 3 members has checked it out
we update the remaining quantity field to the difference so in this case to 1
system can then track who has what checked out by returning all records with a returned date of null
system will then check all records with a returned date of null and then do a date range on the checked out date to determine if the equipment is overdue
send notification to member emails associated with said records from step 6
I would just like some help better understanding the relationship between these and if I have modelled my tables correctly, if not, it would be great if someone can point me in the right direction of improving upon this.
To answer your questions
With respect to modelling in an ERD, I don't think that qualifies as a many-to-many relationship, but rather, EquipmentRentalHistory is its own entity that has a many-to-many relationship with both Member and EquipmentItem.
A many-to-many would be more like, "a Member has access to 0...n EquipmentItems, and each EquipmentItem can be accessed by 0...n Members".
I would disagree that they are a one-to-many relationships.
An oxygen tank and a pair of flippers can both be classified as 'Scuba Gear' and have the status 'Checked Out'.
You could have multiple 'Scuba Gear' tags and assign each unique 'Scuba Gear' tag to its very own EquipmentItem, but then you'll just be creating new tags for every new EquipmentItem, rather than reusing existing ones.
That really depends on whether you want to identify exactly which piece of equipment a member rented (maybe something is damaged you can track down everyone who rented that specific one?). If you do differentiate, then every item will just be its own row. You should also add a new column as an external identifier, but there would be no need to keep a tally.
If it's all the same to you, then I would only keep the total but not the available. If you kept the available column, then you would constantly have to update it whenever something is logged in EquipmentRentalHistory. This would be annoying if the tables fall out of sync. You could just query EquipmentRentalHistory for the Id of the equipment, and count up the entries where returnedDate IS NULL for the number of equipment that is currently in use
Additional Note
It might be good to have a 'due date' column in the rental history rather than hard code the date calculation in case you want to varying due dates. This way you can also grant extensions.
I creating a database for booking system.
Lets consume the following:
Hotel has 20 rooms with the same design, photos, price
So i have an entity like this:
Room:
ID
Hotel_ID
Price
Quantity
How should i perform booking ?
If i consider all the 20 rooms as differ objects, everything is simple:
Room:
RoomID
Status
Price
Quantity
Booking:
BookingID
UserID
RoomID
With the second one approuch administrator has to do much more job and also i have data duplication.
Also i am curios about how to this with the first one approuch.
You could create a third table named 'room-type' or something similar and save there the price, photos, desing, etc.
Then you can create a relation with this table and the room table (where you store 10 records with the ID of each room) so there's not duplicated data and finally make a relation between the room and the booking table.
Using django and python, I am building a web app that tracks prices. The user is a manufacturer and will want reports. Each of their products has a recommended price. Each product could have more than one seller, and each seller could have more than one product. My question is, where do I store the prices, especially the seller's price? Right now I have my database schema so the product table stores the recommended price and the seller's price, and that means one single product is repeated a lot of times. Is there a better way to do this?
Per the recommendations below this is the correct db schema:
Since you have a case of many-to-many then your structure would use a link table. You’ll have tables seller, product and link_seller_product. The last table has a link to the seller table via id as well as the product table via id. This table therefore can also have any information that is dependent on the seller and the product and is not fixed for either. So price-per-product-per-seller goes there.
So add the additional link table with columns sellerid, productid and price and you’ll have only single rows in sellers and products but each seller can have their own price for the product.
You're not adequately representing the one-to-many relationship between products and sellers. Your product table has the seller_id and the seller_price, but if one product is sold by many sellers, it cannot.
Instead of duplicating product entries so the same product can have multiple sellers, what you need is a table between products and sellers.
CREATE TABLE seller_products (
seller_id integer,
product_id integer,
price decimal
);
I'll leave the indexes foreign keys etc to you. Seller ID and product ID might be a unique combination ( historical data is best removed from active datasets for performance longevity ) , but of course any given product will be listed once for each seller that sells it and any given seller will be listed once per product it sells ( along with its unique price).
Then you can join the table back to products to get the data you currently store denormalized in the products table directly :
SELECT *
FROM products
LEFT JOIN seller_products ON ( seller_products.product_id = products.id)
This is a Data Warehouse question.
I would recommend putting prices on a Fact as measures and having only attributes on the Dimensions.
Dimensions:
Product
Seller
Manufacturer
Fact (Columns):
List item
Seller Price
List item
MRSP
Product ID
Seller ID
Manufacturer ID
Timestamp
I am creating a sports collection database of different sports and i am confused of some sort on what tables and primary keys/foreign key combo to use the requirement is as follows:
Should be in a 3rd Normal Form or at least in 3NF.
Here is the Full Description on what I want to do:
Design a database for a sports collection of cards.
You only purchase cards with current market value( at the time of purchase) that are at least $100.00. Your collection about 1000 cards
You collect all kinds of sports cards, from football, basketball, hockey and etc
These cards you collect are produced by different vendors such as ?Topps, Upper Deck, Leaf and Panini.
The collection spans many years of collection, some cards even date back to early 1900s, but there are cards made even before this
The condition of your cards vary too and are grade according to the 10-point PSA grading standards. (Grading table)
Everytime you purchase a card, you must know the date of purchase, cost of purchase, the market value of that purchase, whom you purchased it from, sport, the individual on the cards, card number and etc.
After completion of purchase, you send the card out for grading about a week later, you want to be able to keep track on when the card was sent out for grading, status of the grading, graded assigned to the card , when it was return by the grading company and receipt of the returned card. for tax purposes, you also want to know the fee paid for the grading service (grade table)
you do buy and sell cards, so you also want to know how much you sold the card for for, when it was sold, to whom it was sold, shipping fee if applicable and any relevant data pertinent to sale transaction. You are free to include any additional data that you believe is important to the table.
Here is my current database so far... I feel like i am missing something and I did not follow the requirements properly
It looks like a pretty good start. I have the following observations about your tables/structure:
CardSellers: should only store info about the CardSeller; the only values it should have are SellerID and SellerName
Vendor: should not have CardId
Grade: SellerID doesn't belong here
Card: looks good
CardBuyers should not have DateOfPurchase or CostOfCard or Shipping Fee; those three members belong in CardTransaction. In fact, "DateOfPurchase" should be "DateOfTransaction"
Also, since the Vendor table should only store Vendor data, and the Card table should only store card data, you also need a M2M (many-to-many) table to connect the two; this should have three members: ID (PK), CardId (FK), and VendorId (FK)
UPDATE
Remember two things about table design:
(0) A table should only contain data about the object its named for and only references to other tables (via a FK - see below)
(1) DRY (Don't Repeat Yourself - IOW, don't store the same data in multiple places; instead, store a link to it, where needed, via FK (Foreign Key) fields referencing PK (Primary Key) fields).
As far as the actual design of the tables, this makes sense to me:
CARDS
-----
CardId (PK)
VendorId (FK)
CardFirstName
CardLastName
CardType
CardYear
MarketValue
Rarity
CollectionNumber
COLLECTORS (Buyers and/or Sellers; no need to have separate tables for them)
---------
CollectorId (PK)
CollectorName
CollectorAddress
TRANSACTIONS
------------
TransId (PK)
CardId (FK)
BuyerId (FK) <= CollectorId in the Collectors table
SellerId (FK) <= CollectorId in the Collectors table
TransactionDate
Price (if it may differ from CARDS.MarketValue)
GRADE
-----
GradeId (PK)
CardId (FK)
Points
AssignedGrade
Qualifiers
Status
CardFee
GradedDate
ReturnedDate
VENDORSLU ("LU" stands for "Lookup")
---------
VendorId (PK)
VendorName
CARDTYPESLU
-----------
CardTypeID (PK)
CardTypeDescription
RARITYLU
-----------
RarityID (PK)
RarityDescription
You may find there are other fields you need to add, too, but that should be close. You might even want additional lookup tables, such as for "Qualifiers" and "Status" in the GradeTable.
You might also want a SPORTSLU table, and then add a SportId FK to the CARDS table (where if SportId == 1, it's a football card, if it's 2, it's a basketball card, &c).
Note, though, that as prevalent and historically significant as Relational Databases are, there is another animal called "Non-SQL" databases (such as MongoDB) which are more free-form/loosey-goosey/I'm okay-you're okay/anarchistic, which allow you to have records, or "documents" that can omit or add whatever members it wants on the fly. Relational Databases can be compared to Classical music (Bach, Mozart, &c) whereas Non-SQL are more like Jazz (free-flowing, improvisational).
And BTW, why no mention of Tiddlywinks? Football, Baseball, etc., are fine, but no Tiddlywinks (or Bocci Ball, for that matter)?!?