Doing some practice questions and just wanted to know if I normalized correctly. Thanks.
Un-normalized Table
INVOICE [Invoice#(pk), InvoiceDate, Sales, Cust#,
(EquipClass, EquipClassDesc, Equip#, EquipDesc, EquipCharge, EquipQTY)]
1NF Tables
INVOICE [Invoice#(pk), InvoiceDate, Sales, Cust#]
Equipment [ Invoice#(pk), Equip#,(pk), EquipClass, EquipClassDesc,
EquipDesc, EquipCharge, EquipQTY)]
2NF Tables
INVOICE [Invoice#(pk), InvoiceDate, Sales, Cust#]
Equipment [Equip#,(pk), EquipClass, EquipClassDesc, EquipDesc, EquipCharge]
INVOICE_Equipment [Invoice#(pk) (FK), Equip# (pk) (FK), EquipQTY]
3NF Tables
INVOICE [Invoice#(pk), InvoiceDate, Salesperson#(fk)]
Salesperson [Salesperson#(pk), SalespersonName]
Invoice_SalesPerson [Invoice#(pk)(fk), Salesperson#(pk)(fk), Cust#]
Equipment [Equip#,(pk), EquipClass(fk), EquipDesc, EquipCharge,]
Equipment_Class [EquipClass(pk), EquipClassDesc]
INVOICE_Equipment [Invoice#(pk) (FK), Equip# (pk) (FK), EquipQTY]
Since the Unnormalized, 1NF and 2NF tables never mention a sales person, there's no basis for the splits and additions that occur as you progress from 2NF to 3NF in the prior schemas.
Additionally, an invoice is more probably associated with a customer and a salesperson directly (it would have independent FK references to the customer table (which isn't identified in the schema) and the salesperson table). The Invoice_SalesPerson table looks spurious, and the removal of customer number from Invoice looks dubious. It could be done the way you've shown, but I'd never mark it as correct without a clear, verbose, cogent explanation of why that was necessary (and I'd still be sceptical that it was not necessary).
Related
Can we add our own attributed to the main table during the normalization process.
For example, we have
custid, custname, invoice_date, invoice amount, prod_code, prod_description.
Can I add invoice_ID to the table ?
You have left out a lot of key details making this is a very poor question. Assuming you have have the correct permission/role in any DBMS you can alter any table attributes. The normalisation processes normally comes after you have a draft version of what information you want to represent in each table and then follow the steps of the normalisation process.
http://www.studytonight.com/dbms/database-normalization.php
(Also some advice, you haven't posed any of your DB or even what attributes belong to what table above, in which case if all of the attributes you have listed above belong to the single table this breaks the second/third normal form rule)
An example of a normalised environment:
customers
customer_id*, customer_name
invoices
invoice_id*,invoice_date, customer_id,invoice amount
products
product_id*,product_code, product_description
invoice_detail
invoice_id*,product_id*,quantity
* = (component of) primary key
This assumes that there is a 1:1 relationship between orders and invoices, and that invoices are generated on the date an order is placed.
Table values:
Tabel Desc:
Is it normalized to 1NF, 2NF, 3NF? To the best of my knowledge and if i understand Normalization it cannot be divided again. Am i correct?
We can still normalize the above structure as follows
udegid, userid, designationid,designatedon,revokedon,status
Where udegid is the guid for this table.
Similarly for the department we can have as
udeptid, userid, deptid, effectivefrom, effectiveto,status
This approach enables you to track the history of the employee designation and dept throughout the lifetime of the employee.
HTH
I am having a major issue with relating the following tables together. It is a many to many relationship between Patient and Nurse.
Here is the relational table:
Patient (PatientID (PK), Forename, surname, gender, date of birth, address, illness, prioirty)
seen_by (ID(PK) PatientID(FK to Patient.PatientID), NurseID(FK to Nurse.NurseID) )
Nurse (NurseID(PK), Forename, surname)
The issue I am getting is that, I want the PatientId to be assigned to a NurseID so I know what patient is seen by what nurse. Please note that the ID are all auto_increment values.
Any suggesions, thanks in advance!
Why not create a join table that would be the relationship between the patient and the nurse?
Table: Appointment (AppointmentID (PK), PatientID, NurseID)
Then you can assign the patient and the nurse to the appointment record and keep track of the relationship. This also gives you the benefit of keeping track of additional information regarding the appointment such as dates, prescriptions, etc.
I'm not sure what development environment you're using but Rails has some nice patterns for accessing objects through these kinds of relationships.
I have a simple site where users can bid on a product. The model looks like this:
Obviously different users can bid, so how do I draw the missing link to the 'users' table?
I'm a little confused whether to use identifying or non-identifying relationship.
Updated:
You say: "... users can bid on a product."
This suggests that there is a relationship (Bids) between Users and Products. You could name it user_bids_on_product or just bid.
I would remove the relationship between user and product (unless it means something else like the owner of a product) and unify your bids and bids_has_product into one table:
user_bids_on_product
--------------------
product_id FK to product
user_id FK to user
price
The (product_id, user_id) should not be the Primary Key for this table, as we assume a user can bid multiple times on a product.
You could add a surrogate id and make that the PK or add a bid_number column and make the compound (product_id, user_id, bid_number) the PK. You could alternatively make the (product_id, bid_number) the PK (the bid_number could mark the order of the bids per product, like an auction in this case). I think that's up to you to decide.
Identifying relationships:
Non-identifying relationships:
A User can make one Bid on a Product; a User can Bid on more than one Product; a Product can have more than one Bid; a Bid is associated with only a single Product.
I think you need to have a relationship between a User and the Bids they make. It's one-to-many.
Another question regarding your updated diagram: would a User assign a Rating to a Product, in much the same way they give a Bid? Is that worth tracking? If yes, I'd have a relationship between User and Rating.
A simple identifying relationship b/w users and bids makes sense, bids can't exist without a user.
Its a simple one to many relations, as users "has_many" bids.
I want to know how to design invoice table.
An invoice include many orders from order table.
Is this invoices table is correctly designed?
order
order_id (PK)
User_id (FK)
total_cost
order_date
status
order_item
order_item_id (PK)
order_id (FK)
item_name
cost
invoice table
invoice_id (PK)
invoice_no
invoice_date
period_start_date
period_end_date
status
invoice_order (an invoice with many orders)
invoice_order_id (PK)
invoice_id (FK)
order_id (FK)
Is invoice_order table necessarry?
I could add invoice_id (FK) field in the order_table instead. The "order. invoice_id" would be updated when I have added a row in the invoice table.
You only need the invoice_order table if:
An order can have one or more invoices
AND
An invoice can be linked to one or more orders
By your suggestion at the end of your question, that's the case. You should not just have invoice_id and get it updated when a new invoice comes in, because you would lose the link between the order and the previous invoice.
Update
By the way, it's good that you have cost and item_name in order items, which is something beginners tend to find weird. You have to have those for historical reasons and to make possible to reprint the order with the same data, say, 3 years later, when the item might have had its name slightly changed and cost has surely been updated.
You need the linking table. An order can be in mulitple invoices (if they didn't pay it!) and an invoice can contain many orders. In a linking table though I would not bother with •invoice_order_id (PK). The PK is a combination of the two FK fields. That guarantees uniqueness and since you are unlikely to have a child table of the link table, you really gain nothing by adding a surrogate key to it. Even if you did the performance difference between joining on two indexed int fields vice one would probably be negligible.
Most invoices will have:
Customer ID
Sales Rep ID
Payment Method
Ship to Address
Billing Address
CheckBox: Shipto same as billing
etc.
Generalisation !! You should consider reducing that to 2 tables: Documents and DocDetails. Just add a DocType field in the Documents table, to differentiate Orders from Invoices.
If you need to track backorders, add a Link field to your DocDetails.
When you add an Order detail line, give the Link field the value of the table PK (counter).
When you add an invoice detail line, give the link the same value as the related order detail.
By the way, did not see any CustomerId in your tables !