I encountered Hibernate problem, What's difference between #JoinColumn and #JoinTable in One-To-Many relationship?
Thanks in advance.
JoinColumn uses... a join column to map the asociation:
Order Line
----- ----
id id
... order_id (FK to order.id)
...
JoinTable uses... a join table to map the association:
Order Order_Line Line
----- ---------- ----
id order_id (FK to order.id) id
... line_id (FK to line.id, unique) ...
Related
I'm implementing a role base access control system, for which have the following database tables.
groups
---------
id (PK)
name
level
resources
---------
id (PK)
name
roles
---------
id (PK)
name
permissions
-----------
id (PK)
name
description
users
-----------
id (PK)
name
group_id(FK - references id on groups)
role_id(FK - references id on roles)
Groups has a many-to-many relationship with Resources and Roles. So I have the following junction tables.
group_resource
---------------
group_id(FK - references id on groups)
resource_id(FK - references id on resources)
group_role
---------------
group_id(FK - references id on groups)
role_id(FK - references id on roles)
Here is the issue:
Any given role within a group should have permissions for resources assigned to that group only.
I'm not entirely sure what would be the best way to model the relationship between roles, permissions, and resources in the context of group_resource and group_role relationships .
Any suggestions will be highly appreciated.
Thanks.
Here is a possible solution, with a certain degree of redundancy.
groups (id (PK), name, level)
roles (group_id (FK for groups) ,num_role, name) with PK (group_id, num_role)
users (id (PK), name, group_id, num_role) with (group_id, num_role) FK for roles
resource_types (id (PK), name)
group_resources (resource_type_id (FK for resource_types), group_id (FK for groups) with PK both the attributes
permissions (resource_type_id (FK for resource_types), group_id, num_role, description) with (group_id, num_role) FK for roles
With this solution, the application must check during the insertion of a permission, that the resource appear in the group_id specified in the permission, typically with a trigger.
A way of eliminating at all this redundancy (but it seems to me a less satisfying design), is to eliminate the relation group_resources, since all the information can be found through permissions.
-- Group GRP exists.
--
group {GRP}
PK {GRP}
-- Role ROL exists.
--
role {ROL}
PK {ROL}
-- Resource RES exists.
--
resource {RES}
PK {RES}
-- Role ROL exists within group GRP.
--
group_role {GRP, ROL}
PK {GRP, ROL}
FK1 {ROL} REFERENCES role {ROL}
FK2 {GRP} REFERENCES group {GRP}
-- Group GRP is assigned resource RES.
--
group_resource {GRP, RES}
PK {GRP, RES}
FK1 {GRP} REFERENCES group {GRP}
FK2 {RES} REFERENCES resource {RES}
-- Permission PER exists.
--
permission {PER}
PK {PER}
-- Permission PER is granted to role ROL
-- in group GRP for resource RES.
--
group_resource_permission {GRP, RES, ROL, PER}
PK {GRP, RES, ROL}
FK1 {GRP, RES} REFERENCES group_resource {GRP, RES}
FK2 {GRP, ROL} REFERENCES group_role {GRP, ROL}
FK3 {PER} REFERENCES permission {PER}
-- User USR is assigned role ROL in group GRP.
--
user {USR, GRP, ROL}
PK {USR}
FK1 {ROL} REFERENCES role {ROL}
FK2 {GRP} REFERENCES group {GRP}
-- User USR in role ROL of group GRP,
-- has permission PER to resource RES.
--
CREATE VIEW user_resource_permission
AS
SELECT u.USR
, x.RES
, x.PER
, u.GRP
, u.ROL
FROM user as u
JOIN group_resource_permission as x ON x.GRP = u.GRP
AND x.ROL = u.ROL ;
Note:
All attributes (columns) NOT NULL
PK = Primary Key
AK = Alternate Key (Unique)
SK = Proper Superkey (Unique)
FK = Foreign Key
Suppose I have employees and departments and employee role where one employee can belong to a different department with a different role.
For example, Emp 1 belongs to Dept 1 with a role manager. where the same employee can belong to Dept 2 with a role service-man.
Each employee also has a child hierarchy like Emp 2, Emp 3 belongs to Dept 1 with role assistant and their parent is Emp 1.
In this case what will be the best solution for designing this concept. Please share your opinion.
Consider the entities and attributes:
Employees:
id,
name
Departments:
deptID,
dept_name
Roles:
role_id,
role_name
I'll try to state the business domain as you've outlined it, and then turn that into a schema suggestion.
The system has 0 or more employees
The system has 0 or more departments
The system has 0 or more roles
<<EDIT: your comment says that the "parent" role is department-specific>>
An employee belongs to 1 or more departments, and within that department has exactly one role and one parent (a parent is another employee)
Employee
------------
Employee_id (pk)
Name
Roles
------
Role_id (pk)
Name
Departments
-----------
Department_id (pk)
Name
Employee_deparment_role
-------------------------
employee_id (pk, fk)
department_id (pk, fk)
role_id (pk, fk)
Parent_id (pk, fk to employees)
This model only captures one state - it doesn't allow people to change departments or roles, or "parent", but you didn't mention that as a requirement.
I am creating a SQL Server database that will be used in a web api for both a web application and mobile.
I've always used lookup tables (example: Category Lookup Table) and referenced the IDs (Product Table with CategoryID)
I don't know if I'm doing this using old methods.
Categories (Lookup Table)
---------
CategoryID
CategoryName
SubCategories (Lookup Table)
----------
SubCategoryID
SubCategoryName
CategoryID
Products
--------
SubCategoryID
ProductName
.....
My question is, is this still the proper way? Or do I skip the lookup table and call out the SubCategory directly?
Products
------
SubCategoryName
ProductName
Any advice is greatly appreciated.
You can do it in tow ways
1.
Categories (Lookup Table)
CategoryID
CategoryName
SubCategories (Lookup Table)
SubCategoryID
SubCategoryName
CategoryID
Products
ProductName
CategoryID
SubCategoryID
link both id's with foreign keys, it is normalized way
Answer of your question is here.
if you want more waster way you can approach denormalized structure.
Categories (Lookup Table)
CategoryID
CategoryName
SubCategories (Lookup Table)
SubCategoryID
SubCategoryName
CategoryID
Products
ProductName
Categoryname
SubCategoryname
create an insert/update trigger on Products table to make sure the Categoryname/subCategoryname are valid.Data consistency will be maintained.
You will get faster data from this approach.
I have many tables for example EmployeeType, OrderType, AddressType... etc. these tables has only Id and Name, they look the same so I decided to use only 1 table to simplify the schema here you have the tables:
Type
------------
Id int Identity
EntityId id that represent the table check the table below
TypeId id of each table, EmployeeType, OrderType, etc.
Name Name of the type
Entity
------------
EntityId
Name
Here some example:
Entity table:
EntityId Name
1 EmployeeType
2 OrderType
Type table:
Id EntityId TypeId Name
1 1 1 Employee
2 1 2 Manager
Now I have the Employee table, this table has a TypeId, I need to be able to put a FK to Type table when my EntityId is equal to 1 (EmployeeType) is this possible?
I've a table SCHOOL_PARENT and a table SCHOOL_CHILD. The SCHOOL_CHILD table contains an id for the child and an id for the parent, that togheter forms the primary key. This is because a child can have two parents (mom and father, therefore 2 rows).
Exists then the case of a child without any parents. But I can't insert this row because the table SCHOOL_CHILD doesn't accept a NULL parent, being part of the primary key. How to solve this problem?
Not sure if I've understood the question properly, but I think your data model is something like:
Table: Parent
------------
ParentID (PK)
Name
....
Table: Child
------------
ChildID (PK)
Name
....
Table: Parent_Child
----------------
ParentID (PK)
ChildID (PK)
There is a many-to-many relationship between children and parents; you typically model this in a "bridging" table.
Table: SCHOOL_PARENT
------------
ParentID (PK)
Name
....
Table: SCHOOL_CHILD
------------
ChildID (PK)
MotherID (FK)
FatherID (FK)
Name
....
FatherID ant MotherID can be null.