In my program, I need to make an organization chart starting with individuals and grouping them under a manager, then group those managers under senior managers etc... How do I do this with regards to the database?? This is a many to one relationship - which I thought was illegal and impossible - and would be like starting with the child table - individuals - before creating its parent - manager.
If someone can help point me in the right direction to design my database I'd really appreciate it!!
----EDIT----
Here's a more detailed explanation of my problem:
Let's say a user of my program starts by entering in 35 individuals they'd like to use on some project they're going to work on. Now, there are several possible management positions that can be created and have employees/other (lower) managers assigned to those. The user doesn't HAVE TO create any particular position, but can pick and choose and assign however they like. The only constraints are there will always be a top manager - let's call him the President - and that he SHOULD (but doesn't HAVE TO) only assign 5-10 people to any given manager (president included). So in this example we are starting with 35 individuals and a President. Now we start grouping the 35 individuals into teams and assigning one of them as manager. Say the user decides to have two teams of 6, two teams of 9, and one team of 5 - each of these groups has one of its individual members assigned as manager of that team. So now we have 5 teams, each under its own manager, and those five managers would now be assigned to the President. The program would let this go but warn the user that the number of individuals under a manager in the last team is less than 5 (is only 4). So the user can now (or at ANYtime) go back and change the organization. So let's say he wants to fix this issue and changes up the teams. So he breaks up one of the two teams of 9 and assigns one individual to the team that was short a person. This makes a final count of 3 teams of 6 (5 individual members and one manager), one team of 9 (8 ind and 1 mngr), and one team of 8 (7 ind and 1 mngr) and all 5 team managers are assigned to the president.
Only in real life this can get broken down much further - nests with many more levels of management. How can I do this?
Is Joe Hopfgartner's answer below still valid? Can I just make a "role" column, even though the role would be assigned later (after the row is initially created)? Or changed at any time? Can this self-referencing foreign key be null? (as it would be in the case that no manager has been assigned yet) Or should I move the individuals to a separate "team" table after they've been assigned to a team and move the managers to a "manager" table once they've been assigned as a manager, then add a foreign key for the team table referencing the manager table?
Also, I am using MySQL, so does that fact that you cannot use self-referential ON UPDATE CASCADE or ON UPDATE SET NULL operations affect my particular case (since users will no doubt often be changing the assignments)?
Thank you so much for helping me with this!!!
if one individual can only have one manager, just introduce a "parent person" id field or put managers in a seperate table.
if not, create another table for a relation like "person_has_manager" that assigns a person to a manager.
you can also put managers and persons into the same table and introduce a "role" field, but this can be tricky when using foreign key constraints if you want to ensure that only manages can have persons assigned to them.
to solve this problem you can introduce a "person_is_manager" table that links person to their job as manager, and persons can be linked to be managed by that manager. this ould look like this:
persons
-> person_id (primary)
-> name
-> etc
managers
-> person_id (primary, linked to person_id in persons)
person_has_manager
-> person_id (primary)
-> manager_id (primary, linked to person_id in managers table)
It's a tree. You can use a single table with a parent_id field, to indicate which record is the parent to the current one.
Related
I have been working on a database design and I'm stuck hitting a wall. I'm ending up with what I'm reading is not a normalized database structure but I'm having issues trying to find a "more correct" design and if this design is acceptable how do I execute it in Access?
TLDR: If a table with a single column set as an auto number is an acceptable design, how do you go about inserting a record in it using Access?
The segment of the database of concern is creating a structure for storing companies. Requirements for this is that any changes need to be approved by another user and all historical changes need to be captured so that it can be easily reverted also a company can have multiple aliases but only one legal name.
There is three tables in my solution but one of them is a single column table. From what I've read 95% of people on stack overflow all think its a very bad idea but I've found one post were people are that there are cases for it. I think this is not normal also because I can't find a way to just create a new record in a table with only an auto number column (In Access I have not tried others yet).
Table Structure
Company Names : ID, Company ID, Is Legal Name, Created By, Created On, Approved On, Approved By, Event ID, Is Active
(A company could have a few different names known to the public: TD vs Toronto Dominion. Each name is inserted here with a reference to the company it belongs to)
Companies : ID (Auto Number)
(A company exists and this is its ID)
Companies History : ID, Company ID, Market ID, Holding Company ID, Created By, Created On, Approved On, Approved By, Event ID, Is Active
(These are the historical changes that have been made to the company and who did them and who approved them)
Column Notes:
Event ID : is a FK reference to a table holding each record of actions that have either created, updated or deleted records. (User Research using method [y], Typo Fix, ...)
Is Active : Since deleting records is not possible (historical records need to be kept) this column is used to track if this record is to be included in queries.
Options I see and their issues:
I could get rid of the companies table and make Companies History : ID be the new company id but I find that in that case each time I want to update a company I would need to update each FK reference to the previous company id (I don't think this would be a very normalized approach)
Another Option I see is that I get rid of Companies table and use Company Names : ID as the company id and I would add a column to Company Names called Alias of Company ID. I find that solution adds a log of complexity to my stored data where an alias has company information that differs from the entry that was aliased.
Another Option is that I could add the columns: Created By, Created On, Approved On, Approved By, Event ID and Is Active but this would be duplicating information found in the first record for this company in the Companies History table and this isn't adding any real description to this record.
Anther Option is that I make the Companies table a mirror of Companies History and that when I update or insert a record in Companies I would also insert a record Companies History. With this solution I find that again I duplicate information, that newest record in "Companies History" would hold the same information found in last Inserted or Updated record in in Companies
Another option but is to replace the Companies : ID auto number with a short text and I just get the hash of the current timestamp + a random int. I can now insert new records into this table using access but I feel that this is overkill since I just need the exact same functionality as the auto number.
Another option is move only the legal name into Companies table but now when the legal name of a company changes I have no way of tracking this. Also if I want a list of all names I need to use a union on Companies and Company Names. I find that using unions can reduce performances of queries and I use them only when explicitly needed.
If I don't want to duplicate any information and I don't want to update all FK it seems that I need a table with a single column. If this is acceptable how do I go about inserting a record into a table with a single column set to auto number in Access.
If Companies can be derived from CompanyNames (select distinct CompanyId from CompanyNames), there is no point storing again that information. Just replace that table by a view if you want it (but it as little added value).
On the other hand, if CreatedOn refers to the Company creation (not the row creation) then it is obviously a property of the Company, and I would rather work with
Companies --> Aliases.
But of course I don't know the ins and outs of the reality you're dealing with.
Usually in self realtionship tutorials it is taught in a subordinative way. Eg.: employee X subordinated to employee Y.
I have this scenario bellow where the related players are actually the same person but with different accounts.
So I don't know whether this is right to use self relationship in this case.
(aka: also known as)
aka_id ----> id_player
One player account is not subordinated to another. Players can have multiple accounts but I'm willing to relate them so I can tell they belong to the same person. In the real scenario, there is no master account to relate them to. this is a NON-SUBURDINATIVE scenario.
I thought of not using relationship in this case and insert a random hash key tag to the aka column:
380 | player120 | ae65a3f01a
500 | player430 | ae65a3f01a
The question here is:
Is it right to use self relationships in non-subordinative scenarios?
From the way you describe the problem, you have two entities: players and aka (which I will call nicknames). These are two separate entities, and that usually suggests three tables:
Players
Nicknames
PlayerNicknames
The third table is a junction table that combines the first two. You might be able to put all the information you need about Nicknames in PlayerNicknames -- that is fine. However, if you have a requirement that all nick names be unique, then you definitely want a third table.
My guess is that you have a player name that is automatically a nick name. Great. When you create a player, also create an entry in the nicknames.
We are using an older version of SAP and don't have access to the database itself.
The version is SAP ECC 6.0.
Can anyone tell me where I can find a unique employee Id/ number for an employee?
SAP No is no good as employees can have 2 positions and that would mean 2 different SAP numbers?
Any help would be appreciated.
Thanks
Your question is not really clear on what is the problem, and what you want to accomplish.
I assume you're speaking about the HCM/HR module.
An employee that belongs to several companies will possess several employeeid's. If an employee occupies two positions in the same company, it will have only one employeeid (field pernr in all infotypes tables). However, it has two relationship with "S" objects (Job) in OM.
If you have an employee in several companies, you can create a solution. There are a lot of ways to do so (as always with SAP). It depends also on what (sub) module you want to use ? PA ? OM ?
In the first case, you could use a field of the IT0032 (badge for example), or create a shared infotype, with a GroupId / UniqId that is filled during infotype creation.
In the second case, you could use the "CP" object (central Person) in OM to get a relationship with all the P objects (person / employeeId) of the employee.
It really depends on the HR Processes and the current customization of your SAP system.
SAP HCM has the transaction PA20 which display personnel data. Actually, the right name of transaction is: Display HR Master Data.
Execute PA20.
Look up the field you want.
Hit F1 over there.
Hit over hammer icon.
Look up field name and table name.
OR
to run SE16, accessing the table: PA0105 and column name: PERNR - Personnel number.
I am building a database on Access that, among other things, tracks who has referred patients to our office (I work in an optometrist's office which does a specialized kind of therapy).
I don't have much experience creating relational databases, and I am wondering if I'm heading the right direction. Before posting here, I've asked 5 of my computer programmer friends for help, but suddenly every is busy... So here goes.
1 patient can have Many referrals
my son's teacher and my coworker referred me here (2 referring
sources)
my doctor told me about you, and then I saw your website (2 referring
sources)
1 referral can consist of:
an individual (Dr Blah-Blah, or My Friend Jane Doe)
an organization (Doctors Group)
an individual that is part of an organization (Dr. So-and-So from Doctors
Group)
a media source (website, pamphlet, commercial, tv show, etc)
Often it's not possible to determine which individual at an organization referred the patient (because patients can't remember), so only the organization is recorded. But sometimes it is possible, so the individual and the organization are recorded. And sometimes individuals are not part of any organization.
This is the partial design that I came up with: http://postimg.org/image/uipaq7rrl/
Patients Table
Referring Media Table
stores details of media sources
Referring Organization Table
stores the names/details of organizations
Referring Individuals Table
stores names/details of individuals
uses Ref Org ID as a foreign key, in case individuals are members of an organization
Referrals Table
uses the Patient ID as a foreign key to link the referrals to the patients
How should I link the Referrals Table to the Ref Org, Ref Indv, and Ref Media tables?
I came up with something like this: http://postimg.org/image/qtpoiflmv/
But that seems redundant and leaves a lot of blank spaces, depending on the type of referral: http://postimg.org/image/oepj99ohz/
What should I do? What is a good way to build relationships between these tables?
without even thinking or getting involved, if you see spaces like that, looks like you need a table with referral types
I have an Access application, in which I have an employee table. The employees are part of several different levels in the organization. The orgranization has 1 GM, 5 department heads, and under each department head are several supervisors, and under those supervisors are the workers.
Depending on the position of the employee, they will only have access to records of those under them.
I wanted to represent the organization in a table with some sort of level system. The problem I saw with that was that there are many ppl on the same level (for example supervisors) but they shouldn't have access to the records of a supervisor in another department. How should I approach this problem?
One common way of keeping this kind of hierarchical data in a database uses only a single table, with fields something like this:
userId (primary key)
userName
supervisorId (self-referential "foreign key", refers to another userId in this same table)
positionCode (could be simple like 1=lakey, 2=supervisor; or a foreign key pointing to another table of positions and such)
...whatever else you need to store for each employee...
Then your app uses SQL queries to figure out permissions. To figure out the employees that supervisor 'X' (whose userId is '3', for example) is allowed to see, you query for all employees where supervisorId=3.
If you want higher-up bosses to be able to see everyone underneath them, the easiest way is just to do a recursive search. I.e. query for everyone that reports to this big boss, and for each of them query who reports to them, all the way down the tree.
Does that make sense? You let the database do the work of sorting through all the users, because computers are good at that kind of thing.
I put the positionCode in this example in case you wanted some people to have different permissions... for example, you might have a code '99' for HR employees which have the right to see the list of all employees.
Maybe I'll let some other people try to explain it better...
Here's an article from Microsoft's Access Cookbook that explains these queries rather well.
And here is a somewhat chunky explanation of the same.
Here's a completely different method (the "adjacency list model") that you might find useful, and his explanation is pretty good. He also points out some difficulties with both methods (when he talks about the tables being "denormalized").