We are designing a BI system, and will provide it to everyone who use this system. In this system, everyone has different permission to view different attributes on different people.
For example, CEO in a company has permission to view every people in his company, and every attributes, like phone or email. But leader of a department can only see people in his company, and some attributes of some people should be hidden, but these attributes of other people can be seen by the leader.
How to design a system to handle this problem? The data to be seen will update at any time, and user want to see these data immediately after update.
Related
I am creating the backend of a microservice
that will serve as a tool to see in real time how the company's employees are distributed by projects and what days they have assigned to each one.
The database I have raised looks like this:
The company has 4 departments (Development, Product, Data Science and Operations), but each department of course has its different positions. For example, in development there is Backend, Frontend, SRE and so on for the other departments. My question is if I should create another table for these positions (That is, between departments and employees), or if I should leave the position as an attribute.
To give a little more context, the company is interested in knowing every day how many employees are assigned to projects according to their position, for example, if I have any free backend developer today. If more context is needed to say, please tell me.
If you want to be able to model a future possible situation in which an employee is a member of two or more departments, then yes, you may place a bridge table between employee and department. But if that's not a realistic scenario that you see ever coming, it safeguards integrity better to force the one-to-many relationship the way you have it above. Also, I would point out that your model suggests a task can only be assigned to one employee. Are you sure that's what you want? You may need a bridge table between Tasks and Employees to allow a task to be worked on by more than one person.
Im working on a db to manage customer data for a small company.The customers are companies and institutions (schools..etc) and of course people/contacts. There will be a lot more scope added in time, but right now I'm looking for any input on the core design itself and if there's anything I'm missing here that could cause issues down the road. The image doesn't include the additional lookup tables for items like; country, teltype..etc. I'm kinda worried that I've over-normalised it and it is going to make the queries much more complicated in the long-term. Any input appreciated.
Update - 13/12/2016
I have since created a superclass in my structure called entity, which helps me merge all 3 into one as such. I'm still working on the rest as it has grown quite a lot today, so again any input is appreciated.
The first impression I get looking at the diagram is that you have over-normalised the data (unless that was your aim).
Consider the Company <-> Telephone relationship you have created:-
Creating a relationship like this reads:
A Company can have one to many Telephone Numbers
A Telephone Number can belong to one to many Companies
Evaluating this for a minute; is it likely that a telephone number is shared by more than one Company in your structure? (real-world suggests it wouldn't)
Expanding upon this, I believe the main reason you may have headed down this course would be to allow the same telephone number to apply to one or many contacts as well as a business?
Personally, in my experience, I would suggest a duplication of data (telephone number) maybe easier to maintain and manage from a development perspective. This will make you data structure and application logic less complex, and should make searching less taxing on the system.
However, it will also mean you could end up with stale data, for example, if all of your contacts used the company phone number and the company number was updated, all of the contacts data would now need updating too.
One way round that from an application perspective would be to display the company number with a company contact, then you would not need to duplicate data.
Here is an example of a de-normalised view of this relationship:
You could also apply this to email addresses, where the same concept applies.
Do you need to have bridge tables for telephone, email, and location? If there is no need to have multiple sites, e-mails, or telephone numbers; you can add the attributes to the primary entity.
everyone.
My current goal is to develop database structure for web application-based control system of internet-provider. It is a learning task with following requirements:
The administrator registers the subscriber in the system. System provides services list (Telephone, Internet, Cable TV, IP-TV etc) and different subscription plans for each service.
A subscriber can select one or more services with a certain subscription plans for each service. A subscriber has an account and can
replenish the balance. The funds from the account are removed, depending on the selected subscription plans. If the funds on account are insufficient, the system blocks the user.
The system administrator has the rights to:
add, delete or edit the subscription plans;
register, block or unblock the user.
I think, that all words, highlighted with bold are considered to be entities.
I developed following schema:
And now I have few questions:
Is it OK to have different tables for subscriber and account, or should they be merged(one subscriber can only have one account)?
Should current balance be stored as column in the account table, or should it be calculated each time?
Is it OK to have a table with only ID column?
Any critique and suggestions will be appreciated.
They must be merged, because your model allows links "one subscriber - many accounts".
It's depends on your use cases. For optimization you can add trigger on incoming_payment and update subscriber.balance. So you can very quickly build reports.
Table that contains only generated ID looks bad. In your model service must have property type (Telephone, Internet, Cable TV, IP-TV etc).
As default in CRM while Assigning Account to another account the entire account with job and opportunities is moved to that and I'm not able to view in my account.
While sharing only the account details is shared no the job and opportunity. My requirement is while assigning I should have a copy of the account.
Please Help.
So its not entirely clear what you are asking here. So I'm assuming:
You have a security model where records, e.g. accounts, activities, and opportunities are segregated by owner.
You want to assign an account with its child activities and opportunities to another owner. Whilst the original owner still maintains access to the account.
Couple of options:
Change your security model to remove the segregation entirely.
Implemented a security model with a shared team, where users who want to share records assign records to.
After assigning the account, share it with the original user. (This could be manual, or automatic with customisations). However extensive user of sharing can cause performance issues you should look into.
I need some help with some database design. I am a FE developer by trade and have only dealt with very basic DBs. I am just starting to branch out into more "advanced" web apps and would like some pointers in the right direction for the schema.
What I am looking for is an account system that can basically link two accounts. I will give you the scenario I had imagined off the top of my head.
A user signs up in a regular way, just providing name, email, password for simplicity of this question. After they have signed up, the user can then link their account to another user by entering the others email and having it accepted by the other user.
Once this link has been created, the two users can CRUD tasks together.
The bit I am struggling with is how to create the link between the two users. I obviously have my users table.
USERS:
id
name
email
password
Now, I believe I need to create another table that holds the two linked accounts, that has its own unique ID that we can use to CRUD tasks. Something like:
LINKED_USERS:
id
user1id
user2id
verified
TASKS
id
lu_id (FK, Linked_Users id)
// Any other fields for the two combined here.
Is this correct? If so, how would I setup the relationships between the users table and the linked_users table? This is the bit that is confusing me because I need the relationship to reference two users IDs. Say I wanted to display user1id and user2id names, how would the relationship work? Just really need a bit of help wrapping my head around this.
I hope this makes sense, if you need any more information I will just edit the question.
Thanks for any help in advance!
Your question in not entirely clear as to the requirements. My design assumes the following about requirements:
People are linked together in pairs
Each pair owns zero, one, or more task records.
Each person can be assigned to zero, one, or more pairs. If not currently, then perhaps over time (past pairs, current pairs, future pairs).
I think your confusion revolves around the pairing. Instead think of it as teams. The fact that a team can have at most two people is beside the point; 2, 10, 100 does not matter because any number is handled the same way. That way is a Team table that has members assigned. Each person can belong to one or more teams, and each team can have one or more members. That means we have a Many-To-Many relationship between Person and Team. A many-to-many is a problem in relational design that is always solved by adding a third intermediate or "bridge" table. In this case, that bridge table is membership_.
Each team owns zero, one, or more tasks. Each task is owned by one and only one team. This is a simple One-To-Many relationship between Team and Task.
If these assumptions and constraints are correct, then you would have the following table design in a relational database such as Postgres.
I added a start_ and stop_ pair of fields on membership_ to show the idea that people may have past, present, or future assignments to teams.