I have two tables, one is Persons, and the other is Genders, hence I want to put more than two genders, M, F, Other.
Persons
id INT (pk, ai)
fk(gender_id)
Genders
id INT (pk, ai)
title VARCHAR(255)
What would be the relationship type between Genders and Persons table? Is the relationship between them should be non-identifying or identifying (gender_id has to be primary key too)?
Thanks in advance.
Midori
P.S: (Sorry for grammar mistakes.)
An identifying relationship would be if the gender_id in the Persons table were part of that table's primary key. In other words, if the gender needed to be part of the way to uniquely identify rows in the Persons table.
In the example you show, the gender_id is merely an attribute of the Persons table. It is not used to identify rows. Therefore it's not an identifying relationship.
Related
Let’s assume there are some rows in a table cars, and each of these rows has an owner. If this owner were always a person (conveniently situated in a table persons), this would be your standard one-to-many relation.
However, what if the owner could not only be a person, but also a company (in a table companies)? How would this relationship be modeled and how would it be handled in PHP?
My first idea was to create a column person and a column company and check that one of them always stays NULL, while the other is filled – however, that seems somewhat inelegant and becomes impractical once there is a higher number of possible related tables.
My current assumption would be to not simply create the foreign key as an integer column person in the table, but to create a further table called tables, which gives IDs to the tables, and then split the foreign key into two integer columns: owner_table, containing the ID of the table (e.g. 0 for persons and 1 for companies), and owner_id, containing the owner ID.
Is this a viable and practical solution or is there some standard design pattern regarding such issues? Is there a name for this type of problem? And are there any PHP frameworks supporting such relations?
EDIT: Found a solution: Such structures are called polymorphic relations, and Laravel supports them.
There are multiple ways to do it.
You can go with two nullable foreign keys: one referencing company and the other user. Then you can have a check constraint which assure you one is null. With PostgreSQL:
CREATE TABLE car{
<your car fields>
company_id INT REFERENCES car,
person_id INT REFERENCES person,
CHECK(company_id IS NULL AND person_id IS NOT NULL
OR company_id IS NOT NULL AND person_id IS NULL)
};
Or you can use table inheritance (beware their limitations)
CREATE TABLE car_owner{
car_owner_id SERIAL
};
CREATE TABLE company{
<company fields>
} INHERITS(car_owner);
CREATE TABLE person{
<person fields>
} INHERITS(car_owner);
CREATE TABLE car{
<car fields>
car_owner_id INT REFERENCES car_owner
};
I'm modeling a voting system which has the following entities:
category
nominee
phase
As the name suggest, I'll be storing categories and nominees in the respective tables. The voting will have two phases. In the first phase there'll be 8 nominees per category. The 4 most voted nominees will pass to the second (and final) phase.
So far I have this structure (simplified)
category
id PK
name
nominee
id PK
name
phase
id PK
name
My problem is how to model the voting part. I think I have 2 options, but I'm not sure which one is better or what are the pros / cons of each:
Option 1: Having a category_nominee table with a composite 3 column primary key (I'm pretty sure the "canonical" PK here is formed by these 3 fields; not sure about performance implications; I'm using mysql)
category_nominee
category_id PK
nominee_id PK
phase_id PK
What I don't like about this is that to reference category_nominee from the votes table I'll have to use these 3 columns again, since I dont' have an single identifier in category_nominee. So, in the vote table I'll have to repeat the 3 columns:
vote
id
category_id FK
nominee_id FK
phase_id FK
Additionally, I'm not sure if category_id should point to category.id or to category_nominee.category_id (I'm leaning towards the latter)
Option 2: Create an autoincremented id column in category_nominee and make category_id, nominee_id and phase_id a composite unique key.
category_nominee
id
category_id Unique
nominee_id Unique
phase_id Unique
vote
id PK
category_nominee_id FK
This will simplify referencing a category_nominee record and will avoid some repetition. I expect to have much more records in vote than in category_nominee. Still I'm not sure which option is more convenient.
SQL Fiddle for option 1
SQL Fiddle for option 2
From what I learned about modeling data, option 1 is the good option. Maybe this is the reason for the existence of foreign keys. Never seen option 2.
But in your option 1, category_nominee and vote are duplicates. Implement something like this :
category
id PK
name
nominee
id PK
name
phase
id PK
name
vote
(category_id FK
nominee_id FK
phase_id FK) PK
//others fields required or not
Nothing prevents you from renaming the (category_nominee.)category_id field, if you want unique column names in all your tables. You simply have to link this column to the origin column as a foreign key.
I have a problem in logical design of a SQL Server database.
Still I can not distinct which relation has to be one-to-many and which one has to be many-to-many.
Someone told me if both entity tables are independent, they can have a many-to-many relation, else they will have one-to-many.
But now I am working on a project that collects personal information of the employees, in one part there is a table known as JobStatus which is for the personnel's current job. This table has a relationship with Person (table) that is many-to-many, of course there is a junction table between them.
I made this type of relation because one job position's name is assigned to several persons and with different performance.
For instance :
Person A ----->Operator
Person B------>Operator and so on...
And in other side there are some cases that a person has two Job position, I mean he is either a director and a teacher .
For instance :
Person C ------>Director & Teacher
So would you please guide me in this ambiguous logical mean?
Based on the project you described, I would create three tables: employeeTable, jobType, and jobAssignment. Give each employee a unique id (a primary key) and give each job a unique id (primary key) and let the jobAssignment table be the glue that links the employeeTable with the jobAssignment table. The jobAssignment table would have an index on the employeeID and jobID.
jobAssignment
---------------
employeeID (indexed)
jobID (indexed)
employeeTable
---------------
employeeID (primary key)
employeeName
jobType
---------------
jobID (primary key)
jobName
jobDescription
That way, you can keep track of the employees and their respective jobs in the jobAssignment table no matter how many job descriptions are assigned to each employee.
Simply put, you would recognize a many to many when either table can not have the PK from the other table as its foreign key
Taking a Student and Course table
Student can take many courses
Courses can belong to more than one Students
Putting a FK of course (CourseID) on student will restrict the Student to ONE course
Putting a FK of student (StudentID) on course will restrict the course to ONE student
To solve this, a third table StudentCourse will have the StudentID and the CourseID, therefore making either table independent.
That is Many to Many.
For one to many, that happens when you can easily put the ID of one table as the FK of the other.
In your case, Two Employees can be Operator at the same time and an Employee can be an Operator and Teacher - that design is MANY to MANY. You are right
I have two tables and I need to establish a 1-many relation among them, as an example:
1 Customer can have many Order(s).
What is a good way to create keys on the Order table such that there can be many rows in Orders, relating to one/same Customer details? i.e can I have cases when there are 2 rows with same CustomerID inserted into Order (1-many relation on CustomerID foreign key)
Assume
Customer table has columns:
CustomerID (key)
Name
OtherColumns
Order:
<IsaKeyNeeded>
customerID (foreign key)
OrderName
Another question I have is does 'Order' need to have it's own key?
You have it set up correctly ... the Order table should have a foreign key to the Customer table. This establishes the relationship of one customer to many orders. Just do not make the CustomerID a unique key.
To answer your other question ... yes, the Order table should have it's own primary key.
In database design what do n:m and 1:n mean?
Does it have anything to do with keys or relationships?
m:n is used to denote a many-to-many relationship (m objects on the other side related to n on the other) while 1:n refers to a one-to-many relationship (1 object on the other side related to n on the other).
1:n means 'one-to-many'; you have two tables, and each row of table A may be referenced by any number of rows in table B, but each row in table B can only reference one row in table A (or none at all).
n:m (or n:n) means 'many-to-many'; each row in table A can reference many rows in table B, and each row in table B can reference many rows in table A.
A 1:n relationship is typically modelled using a simple foreign key - one column in table A references a similar column in table B, typically the primary key. Since the primary key uniquely identifies exactly one row, this row can be referenced by many rows in table A, but each row in table A can only reference one row in table B.
A n:m relationship cannot be done this way; a common solution is to use a link table that contains two foreign key columns, one for each table it links. For each reference between table A and table B, one row is inserted into the link table, containing the IDs of the corresponding rows.
n:m --> if you dont know both n and m it is simply many to many and it is represented by a bridge table between 2 other tables like
-- This table will hold our phone calls.
CREATE TABLE dbo.PhoneCalls
(
ID INT IDENTITY(1, 1) NOT NULL,
CallTime DATETIME NOT NULL DEFAULT GETDATE(),
CallerPhoneNumber CHAR(10) NOT NULL
)
-- This table will hold our "tickets" (or cases).
CREATE TABLE dbo.Tickets
(
ID INT IDENTITY(1, 1) NOT NULL,
CreatedTime DATETIME NOT NULL DEFAULT GETDATE(),
Subject VARCHAR(250) NOT NULL,
Notes VARCHAR(8000) NOT NULL,
Completed BIT NOT NULL DEFAULT 0
)
this is the bridge table for implementing Mapping between 2 tables
CREATE TABLE dbo.PhoneCalls_Tickets
(
PhoneCallID INT NOT NULL,
TicketID INT NOT NULL
)
One to Many (1:n) is simply one table which has a column as primary key and another table which has this column as a foreign key relationship
Kind of like Product and Product Category where one product Category can have Many products
In a relational database all types of relationships are represented in the same way: as relations. The candidate key(s) of each relation (and possibly other constraints as well) determine what kind of relationship is being represented. 1:n and m:n are two kinds of binary relationship:
C {Employee*,Company}
B {Book*,Author*}
In each case * designates the key attribute(s). {Book,Author} is a compound key.
C is a relation where each employee works for only one company but each company may have many employees (1:n):
B is a relation where a book can have many authors and an author may write many books (m:n):
Notice that the key constraints ensure that each employee can only be associated with one company whereas any combination of books and authors is permitted.
Other kinds of relationship are possible as well: n-ary (having more than two components); fixed cardinality (m:n where m and n are fixed constants or ranges); directional; and so on. William Kent in his book "Data and Reality" identifies at least 432 kinds - and that's just for binary relationships. In practice, the binary relationships 1:n and m:n are very common and are usually singled out as specially important in designing and understanding data models.
To explain the two concepts by example, imagine you have an order entry system for a bookstore. The mapping of orders to items is many to many (n:m) because each order can have multiple items, and each item can be ordered by multiple orders. On the other hand, a lookup between customers and order is one to many (1:n) because a customer can place more than one order, but an order is never for more than one customer.
What does the letter 'N' on a relationship line in an Entity Relationship diagram mean?
Any number
M:N
M - ordinality - describes the minimum (ordinal vs mandatory)
N - cardinality - describes the miximum
1:N (n=0,1,2,3...) one to zero or more
M:N (m and n=0,1,2,3...) zero or more to zero or more (many to many)
1:1 one to one
Find more here:
https://www.smartdraw.com/entity-relationship-diagram/
Many to Many (n:m)
One to Many (1:n)
Imagine you have have a Book model and a Page model,
1:N means:
One book can have **many** pages. One page can only be in **one** book.
N:N means:
One book can have **many** pages. And one page can be in **many** books.
m:n refers to a many to many relationship whereas 1:n means one to many relationship.
For example:
employee(id,name,skillset)
skillset(id,skillname,qualifications)
in this case the one employee can have many skills and ignoring other cases you can say that it's a 1:N relationship