I have two different entities for employees and managers, but they have one common attribute, in the announcements table is it right even if I did not send any announcement to the employee or manager?
Yes it is,it is actually quite common.
What you got is a bridge table between employee and manager, and you added necessary column to the table, which enhance the bridge table.
If there is no relation ship between employee and manager, if you doun't sed announcement, then ther is no entry in the bridge table, you can chekc i the table if an employee never got such an announcement or how many he got
Related
I'm designing the database schema for a CRM. It has the following tables: users, organizations, contacts, addresses, organization_types.
organizations might be a company, a non-profit or a individual.
users have a many to many relationship with organizations. The reason is because one company, for example, can have a salesman and a manager on the app with two different logins. On the other hand, there is the possibility that a salesman is doing sales for two different companies.
contact and addresses have a one to one relationship with organizations. My client only want a organization to have one of each of those.
I designed it in a way that a organization can also be a client, that would belong to another organization. That would mean that the organization table had a one to many relationship with itself.
That made sense to me because they seem to be the same entity. A client will also need a contacts and addresses table and it could also be a company, non-profit or individual.
The point to consider that another developer raised is that with time, it would be expensive to query the database to differentiate organizations that are our clients from the ones that are clients from our clients.
What is the best approach? Would it be better the make a client_organizations table and separate those two?
I will keep one table and create a column named parent_organization. Parent_organization will be nullable and store primary key of parent organization that child organizations belong to
I have the following relationships (Business rules):
User_Company : Many-to-many (multiple companies per user, multiple users per company)
Ownership : One-to-One (For each entry in relationship table, it specifies whether user is an owner or employee. If owner then a percentage must be there)
Company_ownership : One-to-many for company (Recursive relationship), as another company can also be an owner in a company, percentage must be given.
So ownership or a company can be made up of a number of companies and users.
So I have developed the following:
So does there have to be at least 4 tables for this sort of relationship or can it be simplified.
I feel it is quite complicated and would not be intuitive for another developer? How could it be optimized and elegantly arranged?
I think ownership and employment are different concepts, that would be more advised to have them separated.
Think about John who is one of the owners of A company and in the mean time he is the CTO of A.
Company and People can have a base to reduce redundancy of entities.
Based on the suggestions of Thilo
A separate relationship table was created for owners and employees respectively.
Furthermore, the company_ownership and ownership tables were removed as having a company as an owner is solved by adding an owning_user_id and owning_company_id where one will always be null. The percentage figure is added to this relationship table.
See below:
Here are my requirements:
one user can have many tasks
one group can have many task
one group can have many users
think of it like a facebook group. Invited user in a group can post more than one status. Each user can create many groups.
so it's my database correct? Do I need to specify FK in bridge key?
The design in mysql is correct. If you want to be strict, yes, you do have to enforce integrity using foreign keys in bridge tables.
If a task can belong to only one group you must remove "Task_Group" and add "group_id" into Task table.
I am trying to determine how the tables need to be linked in which ways.
The employees tables is directly linked to a number of tables which provide more information. A few of those tables have even more details.
Employees have a unique employeeid but I understand best practice is to still have a id?
Customers have a unique customerid
Employees have a manager
Managers are employees
Customers have a manager associated with them. manager associated with them
Employees may have a academic, certification and/or professional information.
With all of this said what would be the best recommendation for creating primary and foreign keys? Is there a better way to handle the design?
EDIT
Updated diagram to reflect feedback thus far. See comments to understand changes taking place.
Though your question is sensible, before you go any further in design, I would suggest for you to spend some time understanding relationships, foreign keys and how they propagate through relationships.
The diagram is utterly wrong. It will help it you start naming primary keys with full name, TableNameID, like EmployeeID; then it will become obvious how keys propagate through relationships. If you had full names you would have noticed that all your arrows are pointing in the wrong direction; parent and child are reversed. Anyway, takes some practice. So I would suggest that you rework the diagram and post the new version, so that we can comment on that one. It should start looking something like this (just a small segment)
EDIT
This is supposed to point you to towards the next step. See if you can read description (specification) and follow the diagram at the same time.
Each employee has one manager, a manager manages many employees.
A manager is an employee.
Each customer is managed by an employee who acts as an account manager for that customer.
Account manages for a customer may change over time.
Each employee is a member of one team, each team has many employees.
Employee performance for each employee is tracked over time.
Employee may have many credentials, each credential belongs to one employee only.
Credential is academic or professional.
Employees have unique employeeID but I understand best practice is to
still have a id?
No. (But keep reading.) You need an id number in two cases: 1) when you don't have any other way to identify an entity, and 2) when you're trying to improve join performance. And that doesn't always work. ID numbers always require more joins, but when the critical information is carried in human-readable codes or in natural keys, you don't need a join to get to it. Also, routine use of ID numbers often introduces data integrity problems, because unique constraints on natural keys are often omitted. For example, USPS postal codes for state names are unique, but tables that use ID numbers instead of USPS postal codes often omit the unique constraint on that two-character column. In your case, you need a unique constraint on employee number regardless. (But keep reading.)
Employees have a manager.
Does the table "team" implement this requirement? If the "manager" table identifies managers, then your other manager columns should reference "manager". (In this diagram, that's customers, team, and customer_orders.)
Managers are employees.
And that information is stored in the table "manager"?
Customers have a manager associated with them.
And so does each order. Did you mean to do that?
Employees may have a academic, certification and/or professional
information.
But apparently you can't record any of that information unless you store a skill first. That doesn't sound like a good approach. Give it some more thought.
Whenever you design tables with overlapping predicates (overlapping meanings), you need to stop and sit on your hands for a few minutes. In this case, the predicates of the tables "employees" and "customers" overlap.
If employees can be customers, which is the case for almost every business, then you have set the stage for update anomalies. An employee's last name changes. Clearly, you must update "employees". But do you have to update "customers" too? How do you know? You can't really tell, because those two tables have independent id numbers.
An informal rule of thumb: if any real-world entity has more than one primary key identifying it in your database, you have a problem. In this case, an employee who is also a customer would have two independent primary keys identifying that person--an employee id and a customer id.
Consider adding a table of persons, some of whom will be employees, and some of whom will be customers. If your database is well-designed and useful, I'll bet that later some of the persons will be prospects, some will be job applicants, and so on. You will need an id number for persons, because in the most general case all you can count on knowing is their name.
At some point, you'll have to take your database design knowledge to the next level. For an early start, read this article on people's names.
There are two tables: EMPLOYER and EMPLOYEE. Since each EMPLOYEE is assigned to one EMPLOYER there's 1:N relationship between them - simple stuff.
But I also want to be able to model a situation where each EMPLOYER may be able to choose his one favorite EMPLOYEE (he might as well choose none).
So should I:
1. Add a second 1:1 relationship between those tables - this way EMPLOYER would also contain EMPLOYEE_id_FK. Is having two relationship between two tables even allowed?
2. Add a third table FAV identified by two primary, unique keys - EMPLOYER_ID and EMPLOYEE_ID? This way I would be sure each employer could only have one favorite employee and also each employee may be chosen as a fav only by one employee - which is exactly what I wanted.
What's the proper way to do it?
My recommendation is to have four table. One employee table, one employer table, a table to relate employee to employer (who says an employee can't work for two employers), and finally a table to relate an employer to their favorite employee.
EDIT: Yes, of course there can be two relationships between the same two tables.
You'll need to add an extra table (i.e. four tables instead of three) or to add some kind of is_preferred flag in the employer2employee table).
Yes, it is allowed. You can have as many FKs as you like.
btw: It is a 1:N relationship, not 1:1. And when I would model this it both would be N:M relationships since one Employee can have more than one Employer.
#Nik is right, you could have an employee with two employers, however, an employee can have only one favorite i am guessing, so you only need the FK relationship where Employer is the primary for the FavoriteEmp field in Employee.