I tried setting up a relationship although I don't know if this is how I'm meant to do it:
Category column settings:
Description column settings:
Linked to the table that contains different type of furniture, "Furniture":
Furniture design:
So what I want to do, is make it so that when you choose a furniture category, you can only choose from furniture descriptions of that category:
I do not think this can be done using only tables — you'll have to create a form that will limit the selection in the descriptions listbox based on the category.
Also, there are a number of problems with your data structure:
I imagine multiple Furnitures can have the same CATEGORY. This means that CATEGORY cannot be the primary key -- a uniquely identifying piece of data -- for Furniture. I would suggest adding a Long number column called FurnitureID. If you make this an Autonumber column, every new record will get a new number by default; otherwise you'll have to insert the number by hand.
Once you have such a column, you should have a corresponding column — AKA the foreign key column — in Stock of the same type (or Long if the FurnitureID is an Autonumber). These two columns should be related in the Relationships window. The relationship means that every1 Stock record must have a related Furniture record with the same data in both records.
Once you've done that, there is no need to repeat the CATEGORY and DESCRIPTION fields between the Stock and Furniture tables. This means no duplicate data, and no potential conflicts.
1. Depending on how the column is defined, it might be possible to have no data in the foreign key column in the Stock record; but this is relatively uncommon
Related
I am just started to learn about relational database. When I studied the database of online shopping websites, I found that many examples create a category table and added ID field to the category name. I don't know why they need to create a category table and use category ID as a foreign key to relate products table. What will happen if I remove the category table and add the category name directly to the products table?
What I think is a lot of cases that you want a website menu showing your categories. This menu allows people to view your categories (Men Clothing, Women Clothing, Kids, Accessories) and once they click it they can see the products relevant to them.
If you put the category name to the product, it is very hard for you to update your menu content as you need to loop, group the category in the product table. Also, it is harder to update the category name in product table as a category name could be in lots of product records,
Whereas if you have a category table, you just need to maintain the category table (view what you have in the category table and update DB record if you want your menu change).
In long term maintenance, category table is desired.
In a case I have come over that I would like an empty category which just to show in the website menu (a menu item which contains no product) which is not possible if I do not have a category table.
By inserting just the category name you may complete your POC but you need to understand what is Normalization and why it is needed.
First normal form (1NF) : An entity type is in 1NF when it contains no repeating groups of data.
Second normal form (2NF) : An entity type is in 2NF when it is in 1NF and when all of its non-key attributes are fully dependent on its primary key.
Third normal form (3NF) : An entity type is in 3NF when it is in 2NF and when all of its attributes are directly dependent on the primary key.
Source
What will happen if I remove the category table and add the category name directly to the products table?
Suppose you store the category with each product, and one day your boss tells you that you misspelled a category name. Which one?
"Theater" he says. Or did he say "theatre?" Which is correct? You check and find about "theater" and "theatre" are used close to evenly among the products that have either one.
So which spelling did your boss mean is the mistake, and which one is correct?
If you store the correct spelling in one place, in its own categories table, then you can be sure. You can correct it, and all the products that reference it will implicitly get the correction.
That's an argument for normalization, but keep in mind using an integer id is only a convention. It has nothing to do with normalization. You can use a string as a primary key of a table, and therefore you can use a string as a foreign key in a table that references it.
It's okay to use a non-integer for key columns. As long as there is one instance that stores the canonical value, it satisfies the goal of normalization -- that is to reduce data anomalies.
I am developing an application for making quotations. First you make cost break down (or calculation) and upon that result you add item to quotation. The problem is that i have many product, so each category of a product will have its own cost break down form with different parameters to be filled in. If I will have only one table for cost breakdown, then it will be huge (a lot of fields in table). I have a feeling that this is not the right approach. So I came up with diagram below:
Is this solution even possible, or I must have "N" (if I have N-tables) different FK for each cost break down table? Do you have any better solutions?
I have another question if my linking table "Quotation_QtnDetail" is necessary?
It would be possible to store a reference to a particular value in one of these tables by having a CalculationType column indicating which table the record is in, along with a generic reference ID column (containing the ID of the relevant record). For example, if you were storing a CalcId of 123 and a CalculationType of 2, this would point to the record with ID 123 in the Calc2 table.
The downside to doing this is you're going to lose the ability to validate your data using FK constraints, and it will also make joins to your calculation tables a bit more complicated.
Regarding the Quotation_QtnDetail table, unless a QtnDetail record could ever be linked to multiple Quotation records, there is no need for this extra linking table. Instead, just link it directly by adding a QtnId column to the QtnDetail table. Similarly, you may also be able to remove the Calc_QtnItm table if an item is only ever linked to a single calculation record.
I am supposed to be shipping out a box with variable contents and tracking this in a database. All of my items (the contents of a box) are different types and require different tables to track their respective pieces of information, although each item type has the same length serial number (i.e. PK are the same datatype). And I have a Boxes table.
So each item has a table (~7 tables) plus the box table. I want to create a BoxContents table. I tried to make a many-to-many relationship intermediate table with two columns: one for BoxID and one for ItemBarcode, where BoxID is a FK to the PK on the Boxes table and the ItemBarcode is a FK to each of the PKs on the Items tables (i.e. I tried to link multiple tables to the same column). Unsurprisingly this didn't work. I tried to insert an item and the FK constraint was violated on all but one of the ItemBarcode relationships.
How can I construct my relationships to link several types of items to one box in one table? Is this a logical approach? Do you need more information?
You need a category hierarchy (aka. class hierarchy, subtype hierarchy, inheritance hierarchy...):
There are 3 main strategies for implementing a category hierarchy. If you choose "all classes in one table" or "class per table", then no matter how many kinds of items you have, you only need one "link" table to implement the many-to-many relationship.
My first choice, if the ItemBarcode values are truly unique, would be to:
EDIT: Added description of required triggers.
Add triggers to enforce the barcode uniqueness.
(An insert/update trigger on each item table needs to verify that all (newly) assigned barcodes do not appear in other item tables.)
Use a single BoxId/ItemBarcode table without a FK relation on the barcode side, but with triggers to ensure it remains valid.
(An insert/update trigger on the association table needs to verify that the barcodes exist in the item tables. A delete trigger on each item table needs to prevent, or cascade, deletion of items that are in the association table. An update trigger on the item tables needs to update and changed barcodes in the association table. This last may be integrated into the insert/update trigger in the prior bullet.)
Consider using a view of all items to access common data by ItemBarcode.
My second choice would be n BoxId/ItemBarcode tables for the n item types. Straightforward, but a bit busy. It makes adding a new item type messier than it needs to be.
I would not use a BoxId/ItemTypeId/ItemBarcode table. It denormalizes the data by associating the ItemTypeId and ItemBarcode again, it doesn't allow the use of a FK on the barcode side, and it still requires triggers to ensure integrity.
Don't be afraid of triggers. There are some problems that they can address quite effectively.
Relational databases are not good with this kind of problem. Your basic design is correct - an association table for FKs between the tables.
Your choices are:
Have multiple columns in your association table - one for for each item table
Merge the item data into one item table
I would go option 2.
I'm attempting to design a schema for a consignment store's POS system. I have a master item's table and multiple entities that reference it as a foreign key and contain different attributes. The items table contains all of the information that is common to all items, regardless of its type. The entities that reference any given item offer a specific attribute for that given item type. For example, a "split" item needs an asking price, while a store item needs a cost price.
While this design technically works and enforces only one item in the items table, I'd like to be able to maintain that any given item is only referenced by ONE of these entities. The concern is that I don't want a "split" item to also me considered a "store" item accidently. Is there any way to enforce this through schema design?
The ERD is here: http://randywestergren.com/pos-erd.pdf
The tables in question are phppos_items, phppos_items_entity_split, phppos_items_entity_store, etc.
Thanks in advance!
It seems like you're determining whether or not a item is a "split" or a "store" type by which related row exists. Instead, how about adding a type field to the items table? It won't prevent the other related row from actually existing, but it will let you know definitively that it's an error.
Create a secondary table:
typed_items (poorly named)
{
PK: item_key - this points to the item
PK: int item_type_id - this type code specified which 'type' of item, ie: store, split
// optional, depending on your key design:
// 1...n FK:
// split_item_id,
// store_item_id,
// etc.., if you reference the items PK in the sub-item-type-detail tables, this
// isnt nessicary. if you are using a synthetic key on the sub-item-type-detail
// tables and no key relationship exists you can use this table as a linking table,
// otherwise its not nessicary
}
Since type items key and the type descriminator id are part of a primary key, you know that your model will not allow an item to belong to 2 different sub-item-type-detail tables.
If you want (paranoid) integrity you can now add a constraint on these type-detail tables that ensures the item's key paired with the constant type descriminator value for that type exists in this table.
I have a table for the "Features and benefits" of a list of products. In this table there is an item number, base part number, and three benefit columns. I want to change this to a dynamic table in which they can have any number of benefits, which I can do easily. The problem is the features and benefits do not change between items under the same base part number. For example under the base part "708" the items 708/s, 708/m and 708/l would all have the same features and benefits, so I want to get rid of the redundancy by removing the item column and just have a single entry for each distinct base part number. How would I go about this?
You might need to introduce a 'benefits grouper' field in your table, and relate that to another table with benefitsGrouperID, benefitSequence, and benefit