In an existing SQL Server database, someone has defined the following:
Table Customer has a CustomerID column which is also identity. Then they have defined a relationship where Customer.CustomerID is primary key and Customer.CustomerID is also foreign key. I.e. the relationship points back to the same table and same column.
What is the purpose of this? Seems entirely pointless to me, so I plan to remove this relationship from the DB.
The relation is called a recursive association or reflexive relationship, you will need this type of relationship when you need to present a relationship between two or more elements of the same type.
For example: for presenting a relationship between employees, you could create two tables Employee and Manager. But because the manager is also an employee, you won't need two tables. So we create a recursive association that point for the same entity.
More about recursive association
UPDATE
Setting a column as PK and FK at the same time could also represent the concept of inheritance.
For example:
class Person {
int ID;
string name;
}
class Customer extends Person {
String workPlace;
}
That would result the tables Person and Customer as listed below:
Person
------------
int id (PK)
string name
Employee
--------------
int id (PK, FK)
string workPlace
Related
I have the following tables
Company:
Id,Name
Person:
Id,Name
A company can have one or more directors. A director can be either another company or a person.
To link them I have a table Director:
Director: Id,CompanyId,DirectorCompanyId,PersonId
where if a company is a director DirectorCompanyId has a value and PersonId is null or if a Person is a director PersonId has a value and DirectorCompanyId is null
But I feel like this is not a correct design.
You're right, it's not a correct design. To decompose a M:M relationship into two 1:M relationships you need a third table:
CompanyPerson
--these columns are vital to decompose the many:many relationship
--the PK of this table should be a compound of these two columns
--so that the same person cannot twice work for the same company
--with different roles etc
PersonID -> FK to Person.ID
CompanyID -> FK to Company.ID
--plus other properties like:
RoleID -> FK to Role table --if roles are a defined set of options
StartDate -> --when the person began this employment
ManagerPersonId -> --the person's mananger.. etc
PersonID + CompanyID is the composite primary key for this table
It maps people to companies and the role they have at each. Can also have other info like start date, manager at that Company etc.. (might also need to make start date part of primary key if a person will ever leave and come back to the same co, and you wanted to recycle the PersonID)
Note: You could call this table Employee, because that's effectively what the people inside it are, but I tend to find it more helpful that these middle-man tables that create associations between two other tables are better off called Table1Table2 because you can more clearly see/understand the relationship/purpose of the table than if it's called something more abstract like Employee
The following design seems to be corresponding to demands
Another option is to use inheritance:
Director <-- CompanyDirector
<-- PersonDirector
Hello I have 2 entities that are CUSTOMER and PRODUCT at my Entity Relation Diagram(ER).
CUSTOMER and PRODUCT has a M to N relationship which is RATE and this relationship has 2 attributes which are Comment and Rate.
My PRODUCT entity has a derived attribute named Rating-avg which is the average rating of the product, being rated by the CUSTOMER's.
I don't know and can't find how to add the derived attribute to the table while creating it or altering it.
I would be really glad if someone could help.
I am using SQLite3(3.25.2) and SQLiteStudio(3.2.1) (The latest versions up to date.).
You would use a third table, which is called a "junction" or "association" table:
create table CustomerProducts (
CustomerProductId int primary key,
CustomerId int references customers(CustomerId),
ProductId int products(productId),
Rate ?, -- unclear what the type is
Comment text
);
You could name the table Rate, if you like. I typically name association tables after the two tables involved in the relationship, unless it is an entity itself.
My database structure mainly consists of multiple primary keys per table, therefore multiple columns are required per join. I'm trying to use ColdFusion (11 to be specific) ORM relation property that has a linktable. I think the issue is with two keys on one side of the many-to-many relationship and just one on the other. Here is what I've tried without success:
Table Setup
Staff StaffSites Sites
============ ============ ===========
YearID (PK) --- YearID (PK)
StaffID (PK) --- StaffID (PK) SiteName
StaffName SiteID (PK) --- SiteID (PK)
Staff ORM CFC
component persistent=true table='Staff' {
property name='id' column='StaffID' fieldType='id';
property name='year' column='YearID' fieldType='id';
property name='name' column='StaffName';
property name='sites'
cfc='site'
linkTable='StaffSites'
fkColumn='YearID,StaffID'
inverseJoinColumn='SiteID'
mappedBy='id'
fieldType='many-to-many'
lazy=true;
}
Site ORM CFC
component persistent=true table='Sites' {
property name='id' column='SiteID' fieldType='id';
property name='name' column='SiteName';
}
ColdFusion Error
collection foreign key mapping has wrong number of columns: staff.sites type: integer
If the join table has multiple foreign key columns (that reference the
composite key of the target table), then you must use comma-separated
column names.Also, the order in which the column names are specified
must match the order of composite keys defined.
http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WS5FFD2854-7F18-43ea-B383-161E007CE0D1.html
Composite key should be supported.
Try switching the id's since you define staff id first, and also specify the orm type on the id's just in case. Also, try swapping inverseJoinColumn with fkColumn, I never remember which should be which but that'd be something I'd try.
I have implemented the following ways of storing relational topology:
1.A general junction relation table:
Table: Relation
Columns: id parent_type parent_id parent_prop child_type child_id child_prop
On which joins are not generally capable of being executed against by most sql engines.
2.Relation specific junction tables
Table: Class2Student
Columns: id parent_id parent_prop child_id child_prop
On which joins are capable of being executed against.
3.Storing lists/string maps of related objects in a text field on both bidirectional objects.
Class: Class
Class properties: id name students
Table columns: id name students_keys
Rows: 1 "history" [{type:Basic_student,id:1},{type:Advanced_student,id:3}]
To enable joins by the sql engines, it would be possible to write a custom module which would be made even easier if the contents of students_keys was simply [1,3], ie that a relation was to the explicit Student type.
The questions are the following in the context of:
I fail to see what the point of a junction table is. For example, I fail to see that any problems the following arguments for a junction table claim to relieve, actually exist:
Inability to logically correctly save a bidirectional relations (eg
there is no data orphaning in bidirectional relations or any
relations with a keys field, because one recursively saves and one can enforce
other operations (delete,update) quite easily)
Inability to join effectively
I am not soliciting opinions on your personal opinions on best practices or any cult-like statements on normalization.
The explicit question(s) are the following:
What are the instances where one would want to query a junction table that is not provided by querying a owning object's keys field?
What are logical implementation problems in the context of computation provided by the sql engine where the junction table is preferable?
The only implementation difference with regards to a junction table vs a keys fields is the following:
When searching for a query of the following nature you would need to match against the keys field with either a custom indexing implementation or some other reasonable implementation:
class_dao.search({students:advanced_student_3,name:"history"});
search for Classes that have a particular student and name "history"
As opposed to searching the indexed columns of the junction table and then selecting the approriate Classes.
I have been unable to identify answers why a junction table is logically preferable for quite literally any reason. I am not claiming this is the case or do I have a religious preference one way or another as evidenced by the fact that I implemented multiple ways of achieving this. My problem is I do not know what they are.
The way I see it, you have have several entities
CREATE TABLE StudentType
(
Id Int PRIMARY KEY,
Name NVarChar(50)
);
INSERT StudentType VALUES
(
(1, 'Basic'),
(2, 'Advanced'),
(3, 'SomeOtherCategory')
);
CREATE TABLE Student
(
Id Int PRIMARY KEY,
Name NVarChar(200),
OtherAttributeCommonToAllStudents Int,
Type Int,
CONSTRAINT FK_Student_StudentType
FOREIGN KEY (Type) REFERENCES StudentType(Id)
)
CREATE TABLE StudentAdvanced
(
Id Int PRIMARY KEY,
AdvancedOnlyAttribute Int,
CONSTRIANT FK_StudentAdvanced_Student
FOREIGN KEY (Id) REFERENCES Student(Id)
)
CREATE TABLE StudentSomeOtherCategory
(
Id Int PRIMARY KEY,
SomeOtherCategoryOnlyAttribute Int,
CONSTRIANT FK_StudentSomeOtherCategory_Student
FOREIGN KEY (Id) REFERENCES Student(Id)
)
Any attributes that are common to all students have columns on the Student table.
Types of student that have extra attributes are added to the StudentType table.
Each extra student type gets a Student<TypeName> table to store its specific attributes. These tables have an optional one-to-one relationship with Student.
I think that your "straw-man" junction table is a partial implementation of an EAV anti-pattern, the only time this is sensible, is when you can't know what attributes you need to model, i.e. your data will be entirely unstructured. When this is a real requirment, relational databases start to look less desirable. On those occasions consider a NOSQL/Document database alternative.
A junction table would be useful in the following scenario.
Say we add a Class entity to the model.
CREATE TABLE Class
(
Id Int PRIMARY KEY,
...
)
Its concievable that we would like to store the many-to-many realtionship between students and classes.
CREATE TABLE Registration
(
Id Int PRIMARY KEY,
StudentId Int,
ClassId Int,
CONSTRAINT FK_Registration_Student
FOREIGN KEY (StudentId) REFERENCES Student(Id),
CONSTRAINT FK_Registration_Class
FOREIGN KEY (ClassId) REFERENCES Class(Id)
)
This entity would be the right place to store attributes that relate specifically to a student's registration to a class, perhaps a completion flag for instance. Other data would naturally relate to this junction, pehaps a class specific attendance record or a grade history.
If you don't relate Class and Student in this way, how would you select both, all the students in a class, and all the classes a student reads. Performance wise, this is easily optimised by indices on key columns.
When a many-to-many realtionships exists without any attributes I agree that logically, the junction table needn't exist. However, in a relational database, junction tables are still a useful physical implmentaion, perhaps like this,
CREATE TABLE StudentClass
(
StudentId Int,
ClassId Int,
CONSTRAINT PK_StudentClass PRIMARY KEY (ClassId, StudentId),
CONSTRAINT FK_Registration_Student
FOREIGN KEY (StudentId) REFERENCES Student(Id),
CONSTRAINT FK_Registration_Class
FOREIGN KEY (ClassId) REFERENCES Class(Id)
)
this allows simple queries like
// students in a class?
SELECT StudentId
FROM StudentClass
WHERE ClassId = #classId
// classes read by a student?
SELECT ClassId
FROM StudentClass
WHERE StudentId = #studentId
additionaly, this enables a simple way to manage the relationship, partially or completely from either aspect, that will be familar to relational database developers and sargeable by query optimisers.
I am creating a new SQL Server 2008 database. I have two two tables that are related.
The first table looks like this:
BRANDS // table name
BrandID // pk
BrandName // varchar
The second table looks like this:
MODELS // table name
ModelID // pk
ModelDescription // varchar
Every brand will have at least one model and every model will belong to only one brand.
The question is, should I create a junction table like this
BRANDS_MODELS // table name
RecordID // pk
BrandID
ModelID
Or should I modify the MODELS table to include the BrandID like this
MODELS // table name
BrandID //
ModelID // pk
ModelDescription // varchar
Thanks!
If a model belongs to only one brand then you can put the FK to brand on the model table (your second approach). The first way, with the junction table, is for a many-to-many relation.
Based on what you've said so far, I would leave out the junction table and use an ordinary foreign key in the MODELS table.
But if a model could move brands and you needed to maintain a current junction and history, a junction table has advantages over keeping history of the entire MODELS row when just a foreign key changes. Also if other things exist which might be associated with the relationship "entity" more than the MODEL entity it might make more sense to have a junction table. You can always make a unique constraint on ModelID in the junction table to ensure that the same model is not linked to multiple brands. So although a junction table is required to effectively implement a many-to-many relationship, it can also be useful for one-to-many relationships where that relationship itself has attributes.
Junction tables are used for many-to-many relationships which does not seem to be a good fit here.
For example, you would not want to enable the creation of a Honda Civic and a Toyota Civic. That's an example of car's make/model relationship but should fit your brand/model relationship.