I am using MS-Access database.
I am trying to make relationship with two tables, Old Customer table having data and Newly added coupon table.
As my client want to introduce new concept of coupon, where customer come with coupon instead of giving cash.
I have inserted Coupon code in coupon table in bulk.
Now, I am confused about what kind of relationship I should create with these two tables ?
I have to consider the below things...
customer can give either cash or coupon.
IF customer show the coupon, there will be an entry in CouponID column
as well in cash column (to know the value of that coupon.)
The CouponID should be unique in the customer table, Coupon Code should
not be repeated.
I am confused whether it should be one-To-One or One-To-Many ?
This image will help you to understand the problem.
I would not include "CouponID" in the customer table at all (nor "Cash" for that matter). The customer table models a customer, the coupon table models a coupon.
You need another table to model the transaction:
[CustomerTransaction]
id
date
customer_id
coupon_id
etc...
Every type of independent "thing" should be modeled by a discrete table. and "things" should be related to each other by other tables that create the 1:N relationship.
The relationship of customer to coupon is an optional (ie nullable) one-to-one; your data model looks good.
Some other comments:
The table would be better named sale rather than customer, since if the same customer comes back again, there will be a new row (but with the same name)
You could create a unique index on couponID that ignores nulls
You could rename Cash to Amount; the amount is either "cash" or coupon - the couponID column tells you the type of the amount
To create a unique index that ignores nulls:
CREATE UNIQUE INDEX idx1 ON customer (couponID) WITH IGNORE NULL;
Related
The database has a table called "categories" with columns CATEGORY_ID(primary key) and CATEGORY_NAME.
I have subcategories for each category.
For better accessing which is the best method from the below methods.
Method 1: The "CATEGORY_ID" column in the "categories" table is a FOREIGN KEY in the "subcategories " table.
Method 2: Maintaining a separate table for each category representing the subcategories.
I prefer to use same table for category and sub category
like
Table Categories
[CATEGORY_ID, CATEGORY_NAME, PARENT_CATEGORY_ID]
In case you don't know how many sub categories are there.
This scenario is just an example, the scenario is as follows: We have a product table where all the records of products are stored. Same way we will have customer table where records of customers are stored. The daily sales keep the record of all the sales. This sales table will keep record of which product who has purchased. So linking is to be done from Sales table to product table and customer table.
The query to link the two tables is as follows:SELECT product_name, customer.name, date_of_sale FROM sales, product, customer WHERE product.product_id = sales.product_id and customer.customer_id >= sales.customer_id LIMIT 0, 30
It is better to go with Method 1 since it is more scalable.
Let me elaborate on this. If we go with method 1, we need to maintain 2 tables only that is Categories and Subcategories. In future if we have new categories or subcategories we can directly deal with this 2 tables.
If we consider same situation with Method2 then we need to create new tables every time, this may become maintenance overhead.
Let me be a bit more direct. You explain in a comment that Method 2 is a separate table for each category. If so, then Method 2 -- in general -- is just wrong.
There are two methods for storing this type of information. One is a Categories table with a (single) Subcategories table. The Subcategories table would have CategoryId, a foreign key reference back to Categories. This is the normalized data model.
The second method is to store everything in one table. Each row would be a category/subcategory combination. Information about a given category would be duplicated across multiple rows, so this is not a normalized approach. However, this is a typical approach when doing dimensional modeling for decision support systems.
If the subcategories are just names of things, there is a third approach, which would be to store a list of the subcategories within each Category row. The list would not be a delimited string. It would be JSON, a nested table, XML, array, or similar collection data type supported by the database you are using. I am mentioning this as a possibility, but not recommending it.
I know this is probably a stupid question to some but I'm required to have this database in 3NF but know very little about normalisation as our teacher has not covered it. Could someone give me a simple yes or no answer as to whether it is in 3NF and if it is not, suggest any changes. Thanks.
Simple answer No. Google transitive dependencies, or even just Google 3NF?
Why is this the case? Because you have some columns that are dependant on other columns in the same table, where those columns aren't part of the primary key.
For example, in your Customer Table you have Postcode and Town, but there is a relationship between the two, i.e. you couldn't have a Postcode for Paris without also having a Town of Paris. This is very weak transitive dependence, and most databases would have this without considering it bad practice, but I think this is enough to break 3NF.
There's another place where it's a little less clear, but I am pretty sure you break 3NF. In your Payment Table you have Deposit Paid, Total Price, Amount Still To Pay, and Fully Paid. There's an argument that given Total Price and Deposit Paid you could determine Amount Still to Pay. There's a very strong argument that you could always determine Fully Paid from the other three "paid" columns.
You can create Person table with id,title,firstname,lastname
You can add person_id to customerTable and employeeTable. And remove title,firstname,lastname fields from that table.
You can create TownTable with columns id,name and then add town_id to customerTable and emloyeeTable. Remove column town ftom that tables
Create contactInfoTable with columns id, contact_type_id, contact_info
Add contact_info_id column to employeeTable and customerTable. Delete another columns about contact info (phoneNo,email) from that tables.
Create contactType table woth columns id,name. Fill two rows to that table with names phone and email
Create personAddress table with columns id, address, town_id
Add personAddress_id to customerTable, employeeTable tables. Remove address,town from that tables
Create TownTable woth columns id,name
You can create userTable with columns id,employee_id,username
You can create passwordTable with id and user_id
Create user_role table with id, user_id, role_id
Create role_table and add id,name
Also add create_date,end_date (Date ), active(nvarchar2(1) or integer) to all your tables. And in your selects use active=1 condition.
i am new to dimension modeling and OLAP.
I am trying to create a dimension model for a shop.
"order" table is having columns:
'order_id(auto generated), total_order_cost, date, product_Set_Id'.
"Product_set" table (contains products ordered in each order i.e. multiple rows for each order, tables logically linked by 'product_set_id' column) has columns:
'product_set_id, product_name, quantity,Cost_per_quantity'.
In the ER model "product_set" table is kind of weak entity dependent on "order" table.
My doubt is in the fact table
case 1: i should add only 'order_id(fk)' and 'total_order_cost(as measure)'
==>in this case measures from "product_set" won't be there in fact table.
or case 2:i should add 'order_id(fk)','product_set_id(fk)' and 'cost_per_quantity(measure), quantity(measure), total_order_cost(measure)'
==>in this case there will be multiple rows for same 'order_id' and 'total_order_cost'
There are other some tables like "customer" etc but i have doubt in above mentioned.
Thanks in advance!
one suggestion always made is to create a surrogate key on the tables. My fact sales is such that it has the surrogate key which allows me to have the orderline data there and each orderline identified by a surrogate key (which I don't really use - but its not an issue) . That way you can follow case 2.
Does that answer the question?
New to VBA and Access so hope I can explain this correctly.
I have two tables , Orders and Deliveries.
Orders include OrderNo, CustomerName, CustomerAddress, CustomerContact and so on.
Deliveries include DeliveryNo, OrderNo, DeliveryDate, DeliveryType and so on.
I have created a relationship between these two tables linking them between OrderNo as I require the CustomerName when creating a Delivery from an Order.
However sometimes a Delivery is manually inserted into the table using a form. A CustomerName is required for this record but there is now no corresponding OrderNo.
I am not sure how to set up my table to accommodate manual entries.
Appreciate the help, thanks
It sounds like the business requirement is to be able to insert deliveries into the delivery table without a corresponding order number. If this is the case, you need to relax the constraints on the table and remove relationship between Delivery.OrderNo and the Orders table. Otherwise, you could populate this field with a special number (0 or -1) to indicate no order in this circumstance if you need to enforce the foreign key relationship for other reasons. It all depends on how you wish to enforce the business logic.
What if you just added a CustomerName field to the form?
For what I understood of your question, you use the Orders table to generate the Deliveries, so for each order in the Orders table you would add/generate a record to the Deliveries table. Now, when you add a delivery manually(using the form) I suppose there is no order associated with it, hence no Customer Name. In that case the only solution would be to add a field called CustomerName to the mentioned form (I suppose the person who is manually inserting the Delivery knows the name of the customer) and any other field you need, and if your business logic requires it you can create a "virtual" Order with the same OrderNo as the inserted delivery.
I'm creating a small pet shop database for a project
The database needs to have a list of products by supplier that can be grouped by pet type or product category.
Each in store sale and customer order can have multiple products per order and an employee attached to them the customer order must be have a customer and employee must have a position,
http://imgur.com/2Mi7EIU
Here are some random thoughts
I often separate addresses from the thing that has an address. You could make 1-many relationships between Employee, Customer and Supplier to an address table. That would allow you to have different types of addresses per entity, and to change addresses without touching the original table.
If it is possible for prices to change for an item, you would need to account for that somehow. Ideas there are create a pricing table, or to capture the price on the sales item table.
I don't like the way you handle the sales item table. the different foreign keys based on the type of the transaction is not quite correct. An alternative would be to replace SalesItem SaleID and OrderId with the SalesRecordId... another better option would be to just merge the fields from InStoreSale, SalesRecord, and CustomerOrders into a single table and slap an indicator on the table to indicate which type of transaction it was.
You would probably try to be consistent with plurality on your tables. For example, CustomerOrders vs. CustomerOrder.
Putting PositionPay on the EmployeePosition table seems off to... Employees in the same position typically can have different pay.
Is the PetType structured with enough complexity? Can't you have items that apply to more than one pet type? For example, a fishtank can be used for fish or lizards? If so, you will need a many-to-many join table there.
Hope this helps!