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.
Related
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.
1- Message belongs to name, Name belongs to Email and email belongs to phone number
2- Message belongs to email, email belongs to name and name belongs to phone number
3- many messages can point to a single email and name and phone number.
Message belongs to email, message belongs to name, message belongs to phone number.
Or is there any better structure which would satisfy normalization.
The purpose of this from is to store data so that the telecaller can later contact the person who contacted via email and phone number
You are not phrasing your requirements properly. So we cannot provide a precise solution.
Entity
Instead of thinking about columns and fields, think about entities. What are the real-world things you are trying to track in your database and app.
If doing an appointment scheduling system for an veterinary practice, you have several entities: Customer, Animal, Doctor, MedicalAssistant, Appointment/Visit.
If your tracking employees communicating, you have Employee and Message.
Attribute
After identifying entities, you identify attributes. What aspects of each of your entities do you care to track in your database and app? For example, your employee’s have a height and a hair color as attributes, but those two are irrelevant to your messaging app. On the other hand, each employee has conduits of communication as attributes, perhaps having an email address, an office phone, and a personal mobile phone, as examples. Again, you must ask which of those you care to track.
Relationship & Cardinality
If you want to look up the employee's email address or phone, but track messages without regard to mode of communication, then we have two tables. The relationship is that each employee can have zero, one, or more messages, and each message must have exactly one employee. This quantifying of related rows between tables is known formally as cardinality.
In my ASCII-art equivalent of crows-feet ERD diagramming:
[employee]-1-----0-1-<[message]
As for columns on those tables:
Current name, current email address, and current office phone number extension are all attributes (columns) on the employee table.
The message table has a column content.
Keys
The employee table also must have a primary key column. The primary key is usually an identity column (auto-incrementing sequence of integer numbers) or a UUID.
The message table as wall carries a primary key column. In addition, the message table must have a foreign key column. The foreign key column contains the value of the primary key of the employee to whom the message was sent.
I'm designing the relational database for a system that stores information about certain types of products, retailers and suppliers for the retailers.
Some of the suppliers sell the same products - however, they don't have a standard for identifying the products which means supplier A might have a product with id 618261 that is equivalent to supplier B's product 007162.
The problem is, I don't want to store the same product multiple times for different suppliers. Currently, I have the following tables:
equivalence
supplier1_id
supplier2_id
supplier1_product_id
supplier2_product_id
product
id (generated)
supplier_id
supplier_product_id
This seems like a bad idea. Whenever something is inserted into 'product',
'equivalence' must be queried to find every equivalence
'product' must be queried to find if equivalent products are already stored
if equivalents are not found, the product can be inserted
Is there a smarter way to do this?
This is not an uncommon scenario, different suppliers many times will have their own SKU numbers for a common product. Additionally, a product may have different manufacturers each with their own part number. But let's look just at the suppliers.
In plain English, a supplier may supply many products and a product may be available from many suppliers. This many-to-many relationship is maintained via a cross or intersection table. If you think about it, the SKU number is not an attribute of the Product entity or of the Supplier entity. Instead, it is an attribute of the relationship. Yes, relationships may have attributes just as any entity.
create table ProductSupplier(
ProductID int not null references Products( ID ),
SupplierID int not null references Suppliers( ID ),
UnitPrice currency not null,
SKU varchar
);
The UnitPrice could well be a list of per-unit prices that would vary according to the volume ordered. Thus it would likely be in another table -- I've added it here to show an additional supplier-product relationship attribute.
Again in plain English, a tuple from this table says, "this product from this supplier has this SKU number."
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)?!?
its about internet shop program.
Customer, products, Order, and supplier is involved.
How to implement that the customer can be a product supplier in the same system ?
How to design it and what is the idea to impelemnt it ?
this is what i have tested but im not sure if i did right.
I believe that you are on the right path. The customer entity is different from the supplier entity. As a result, if a user is both a customer and supplier, he will have both a supplierID and CustID. This is shown in your diagram by the relationship with the User entity. However, the Customer entity will need to have a foreign key to link it to the User table. this will likely be UserID. Same for the Supplier entity.