I have following entities in my database:
Folder
Set
Group
Item
An Item is related to only one Group. However A group can belong to a folder or set which in turn can belong to either folder or set.
Something like this
Item1->Group1
Group1->Folder1->Folder2
Group2->Set1->Folder3
I am trying to map this to relational database in SQL server.
This is how I am mapping currently
Separate tables for each
1. Folder
2. Set
3. Group
4. Item
Item table will have ParentId as Group ID
However I will have one more Table ParentChildMapping which will have
ChildID ParentID (either of them can map to any of FolderID, SetID or GroupID)
Is this a good approach or is there any better approach?
Thanks,
You should consider an entity-subtyping approach for Folder/Set/Group and use a recursive one-to-many relationship to record the parent/child relationship at the entity-supertype level.
This might look something like this:
Table: Container (super-type)
- ContainerID PK
- ParentContainerID NULL FK (to self)
Table: Folder (subtype)
- ContainerID PK FK
- (other folder columns)
Table: Set (subtype)
- ContainerID PK FK
- (other set columns)
Table: Group (subtype)
- ContainerID PK FK
- (other group columns)
Table: Item
- ItemID
- (other item columns)
- ContainerID (FK to GROUP)
Related
I wish to define a relationship between a parent->child table.
The field in the parent table is a non key attribute(relation_field_A). I would like to define a relationship between the parent table and the child table via the relation_field_A field. I want to ensure that a value in Table_B.relation_field_A exists in the Table_A.relation_field_A.
What I want is a non-identifying relationship between the parent and child table. Is this possible?
Table_A
------
Key_A - PK
field1
feild2
relation_field_A
Table_B
-------
Key_B - PK
field1
field2
relation_field_A
If you want to make a foreign key from Table_B to Table_A, then the column in Table_A must have at least an unique index
create unique nonclustered index UX_TableA on table_A (relation_field_A)
See this example
Without this, you would allow a child to have a link to more than one parent, which is not allowed. In a master-child relationship a parent can have 0, 1 or many childs, and a child can have only one parent.
If that is not what you want than you maybe are after a many to many relation ship ?
For that you need a third table which links both together.
There are many examples on google about many-to-many relationships
And if you really just want to ensure that the relation-field-a in Table_B exists in Table_A without an unique index than you cannot achieve this with a foreign key, you could write a trigger on both tables to try to ensure this.
But honestly, it seems like a design flaw has been made somewhere here.
I would like to know if it's ok to define a relationship for a column of a table and say it's a foreign key of the same id column from the table.
Example:
Tbl. Name: Categories
Column 1: id
Column 2: name
Column 3: parent_id
Parent_id should contain (only if it's necessary) the id of the category.
I want to make a tree structure of my categories.
Is it ok to do this?
Yes, when it is appropriate. Which it is in the case you describe for a Parent-Child relation of the same table.
I’ve encountered a problem with pulling multiple foreign keys into one record in a Microsoft Access table.
I’ve got two tables with these fields:
Table 1:
Owners
Fields:
Owner ID (Primary Key)
First Name
Last Name
Table 2:
Ships
Fields:
Ship ID (Primary Key)
Ship Name
I need to create a relationship between Table 1 and Table 2 which shows who owns the ship. I’ve tried adding a number field to Table 2 called Owner ID (Foreign Key) and this works absolutely fine.
Working Example:
Table 1 – Owners Table 2 – Ships
Owner ID (Primary Key)__ Ship ID (Primary Key)
First Name \ Ship Name
Last Name \________Owner ID (Foreign Key)
Unfortunately my ships in Table 2 can have multiple owners (up to 5) at the same time. My problem arises when I try to create a series of linking fields in Table 2.
Not Working:
Table 1 – Owners Table 2 – Ships
Owner ID (Primary Key)__ Ship ID (Primary Key)
First Name \ Ship Name
Last Name \ Owner1 ID (Foreign Key)
\______/ Owner2 ID (Foreign Key)
\ Owner3 ID (Foreign Key)
Can anyone recommend any workarounds so I can show multiple owners taken from the Owners table in the Ships table?
Thanks for your help!
Your database design is definitely incorrect.
In the case you explain, you have a many-to-many relationship between Ships and Owners, which MUST translate into a "relationship table" in the relational model.
In this case: a [Ownership] table, with 2 fields, being the 2 Primary Keys (PK) of the related tables.
In other words, you need 3 tables:
Ships(ShipId, ShipName, Whatever) PK is ShipId
Owner(OwnerId, FirstName, LastName) PK is OwnerId
OwnerShip(ShipId, OwnerId) PK is made of the 2 FKs
The problem is that it looks like Access doesn't allow Nullable FK's and so all Owner fields would have to be filled in, no matter how many owners there are.
The only solution to this I can think of is to introduce a ShipOwner table, which has ShipID and OwnerID columns (as FK's to the Ship and Owner tables). You can then have as many Owners as you like.
Pros: You can add things like %Owned if that matters
Cons: The software has to enforce the limit of 5 owners
Biggest Pro: it will work!
Cheers -
EDIT: The first para is wrong: Access does let you add nullable FK's. However I still thing the suggestion here is a good one. Repeating Groups (Owner 1 to 5) is against Normalisation rules, and this suggestion is normalised.
Old version
I have a Person table and the table Company.
both tables have a column Id (Identity)
Table Company have Ids of 1 to 165
In the table Person have Ids 1 until 2029
New Version
In the new version of the system, was created a table Entity.
This table contains the records of the Companies and People
The Company and Person tables will be maintained, referring to the Entity table.
The Id in table Entity will be the same in Company or Person table
Question
Both tables have multiple relationships with other tables.
Table Entity (as well as others) has a column ID (identity).
The problem is that the Id were repeated when the two tables together (It was to be expected).
How to import without losing relationships?
Attempts
I thought of changing the value of Ids in Company table, starts from 2030.
Thus the Ids would not duplicate when joining the two tables.
But this creates another questions.
How to do this without losing existing relationships?
How to change the Id of a row in the table and this is reflected in all tables which it relates?
I would like to do this using only DDL (SQL Server)
I thought of changing the value of Ids in Company table, starts from 2030. Thus the Ids would not duplicate when joining the two tables.
Create foreign key constraints on the Person table to all related tables (or alter the existing foreign key constraints) with ON UPDATE CASCADE. Then update the Person table and change the values if the id columns - these changes will cascade to the related tables.
To stop further problems, maybe change the identity columns in Person and Company to something like identity( 1000, 3 ) and identity (1001, 3) respectively.
However, I think the best idea is to have a different EntityID column in the Entity table, unrelated to PersonID and CompanyID. The Entity table would also have a column called AltEntityID or BusinessKey that contains the id from the other table and that does not have a unique constraint or a foreign key constraint.
And if you make small modification to your attempt - add new column, say newId, to Company and to Person to manage relation with Entity and leave id columns as is. Why this is the simpliest way? Because new columns shouldnot be identity columns, from one side. From the other side, you can leave all logic of relating other tables with Company and Person intact.
I have a table that contains all products. There are 3 distinct types of products so these have their own tables, lets say ProductType1, ProductType2, ProductType3.
There is a 1-1 relationship between Products and ProductType(n) on ProductId, but to further constraint the child tables there is an additional relationship using a ProductId, ProductTypeId in Products, and a ProductId, ComputedProductTypeId in each of the other tables.
This ensures that a product can only be added to a single matching ProductType table.
The question is this. As there is already a relationship between the 2 tables on ProductId, rather than using an index for the FK, can I get away with a unique key to constrain the relationship, or will this cause performance issues?
Products
PK ProductId
FK ProductId, ProductTypeId
^
*Add an index for this or unique key constraint?*
ProductType(n)
PK ProductId
FK ProductID, ComputedProductTypeId (fixed int)
Creating an index will be better approach.
If you want to delete entries from your master table, SQL server looks for FK relations if any exists. So Creating Index on your composite key (which includes FK) will speed up the process.