I have to model and create in a SQL Server database a simple relationship...
A Team can have zero or more Employees assigned to it; An Employee can only be assigned to a single team. Simple enough... Here is the twist that I am struggling with...
The Team has a TeamLeader, who is an Employee. A TeamLeader can be assigned to a single Team. So, I added the TeamLeaderId long to the Team and gave TeamLeaderId a unique index. I created a foreign key relationship between the TeamLeaderId in Team to and EmployeeId in Employees.
Is this the best model for this situation, or is there a better pattern?
Thank you for your help and guidance,
Mike
For the constraints you laid out this looks right. But it seems you would be better off with a link table between Team and Employee. Why limit an employee to a single team or make it mandatory for an employee to be in a team at all? Today someone (you?) may think this is the only way, tomorrow it may be different.
It is better to remove TeamLeaderId field from Team table and create new table TeamLeaders (with an unique key [EmployeeId in Employees + TeamId in Teams])
Now, you can change your mind and remove team leaders from your business domain model without pain: just drop teamleaders table.
I think the answer to this question depends much on the usage of the system:
If the Team is created and employees assigned, and then finally the team leader is chosen among any of the team members, its a good choice you have made.
On the other hand, if an employee is hired as a team leader, and he will always be assigned as a team leader it is better to add this "type" of information to the Employee table (othervise adding/removing an employee requires extra uneeded logic to handle the TeamleaderId and potential future "types").
Related
I work in cattle production and I am learning about database design with postgreSQL. Now I am working on an entity attribute relationship model for a database that allows to register the allocation of the pastures in which cattle graze. In the logic of this business an animal can be assigned to several grazing groups during its life. Each grazing group in turn has a duration and is composed of several pastures in which the animals graze according to a rotation calendar. In this way, at a specific time, animals graze in a pasture that is part of a grazing group.
I have a situation in which many grazing groups can be assigned to many animals as well as many pastures. Trying to model this problem I find a fan trap because there are two one-to-many relationships for a single table. According to this, I would like to ask you about how one can deal with this type of relationship in which one entity relates to two others in the form of many-to-many relationships.
I put a diagram on the problem.
model diagram
Thanks
Traditionally, using a link table (the ones you call assignment) between two tables has been the right way to do many-to-many relationships. Other choices include having an ARRAY of animal ids in grazing group, using JSONB fields etc. Those might prove to be problematic later, so I'd recommend going the old way.
If you want to keep track of history, you can add an active boolean field (to the link table probably) to indicate which assignment is current or have a start date and end date for each assignment. This also makes it possible to plan future assignments. To make things easier, make VIEWs showing only current assignment and further VIEWs to show JOINed tables.
Since there's no clear question in your post, I'd just say you are going the right way.
I've read through a bunch of tutorials to the best of my ability, but I'm still stumped on how to handle my current application. I just can't quite grasp it.
My application is simply a read-only directory that lists employees by their company, department, or sorted in alphabetical order.
I am pulling down JSON data in the form of:
Employee
Company name
Department name
First name
Last name
Job title
Phone number
Company
Company name
Department
Company name
Department name
As you can see, the information here is pretty redundant. I do not have control over the API and it will remain structured this way. I should also add that not every employee has a department, and not every company has departments.
I need to store this data, so that it persists. I have chosen Core Data to do this (which I'm assuming was the right move), but I do not know how to structure the model in this instance. I should add that I'm very new to databases.
This leads me to some questions:
Every example I've seen online uses relationships so that the information can be updated appropriately upon deletion of an object - this will not be the case here since this is read-only. Do I even need relationships for this case then? These 3 sets of objects are obviously related, so I am just assuming that I should structure it this way. If it is still advised to create relationships, then what do I gain out of creating those relationships in a read-only application? (For instance, does it make searching my data easier and cleaner? etc.)
The tutorials I've looked at don't seem to have all of this redundant data. As you can see, "company name" appears as a property in each set of objects. If it would be advised that I create relationships amongst my entities (which are Employee, Company, Department), can someone show me how this should look so that I may get an idea of what to do? (This is of course assuming that I should use relationships in my model.)
And I would imagine that this would be the set of rules:
Each company has many or no departments
Each department has 1 or many employees
Each employee has 1 company and 1 (or no) department
Please let me know if I'm on the right track here. If you need clarification, I will try my best.
Yes, use relationships. Make them bi-directional.
The redundant information in your feed doesn't matter, ignore it. If you received partial data it could be used to build the relationships, but you don't need to use it.
You say this data comes from an API, so it isn't read-only as far as the app is concerned. Worry more about how you're going to use the data in the app than how it comes from the server when designing your data model.
Alright I can't seem to wrap my head around the subject normalization.
I have this table
Now I need to find the full functional dependencies.
FilmID, Actor -> Title, Year, Director
Publisher -> PublisherCity
Actor -> DOB, Country
Now Can someone tell me if I'm on the right track? if not then any help would be appreciated.
Tables
fields
I hope this helps:
films
id
title
year
director_id
publisher_id
One publisher and director only with this setup.
actors
id
name
dob
country
you missed name from Actor attrs
films_actors
film_id
actor_id
This is a join table of films to actors. Allowing you to link limitless actors to films (Many to Many relationship).
publishers
id
name
city
self explanatory
directors
id
name
self explanatory
any questions just ask.
If you are asking "how can I design" relationships, well one thing is practice and reading the right books. Here is a short cut ->find the cardinality of any relationship.
For e.g. Consider books and author's. One author can write multiple books so the cardinality is multiple on the book side. This is called one to many relationship. Now with practice you learn that this can be modelled in a relational db using a foreign key. Like the director_id in films table of #Isotope's answer
Now consider that some books(for e.g. the professional series) can be written by multiple authors. Now cardinality is multiple on both sides of the relationship. This is known as many to many relationship. You can design this relationship using film_actors kind of mapping table from above answer. For basic modelling this much is more than enough. Do take a look at this excellent article on infoq which might help you in this.
So I'm having a problem modeling this in Mongo/Mongoid:
Teams can participate in an event and each event will have results for each team (score, actions leading the the score, etc.)
Basically I want to display a scoreboard of sorts for the event.
So here is what I have:
Event
has_and_belongs_to_many :teams
Team
field :name
field :color
has_and_belongs_to_many :events
This works fine but I need to know how to model the relationship between each team and the event.
TeamEventStats (probably not the best name)
field :score, :type => Integer
# etc. etc.
In ActiveRecord/RDBMS I could do a through (join) model and go on my merry way but
I don't know how to do this in Mongo.
Anyone know a good way of doing this or a better way of modeling the relationship?
this may help u out. http://mongoid.org/docs/relations/referenced/n-n.html
A has many through is really just a couple many-to-one's to create a many-to-many, with the added bonus that you can store relationship data in addition to the foreign keys (like your team stats). So you can easily accomplish this in Mongoid using something like:
Event
has many :team_stats
Team
has many :team_stats
TeamStat
belongs_to :events
belongs_to :team
field :score, :type => Integer
There's nothing hierarchical about this though. If you need to be able to query both (give me the stats for all team for Event A, also give me the stats for all events for Team #1) then it's primarily a relational schema. Know what I mean? So unless you have a lot of other hierarchical / document based data in the app, I'd probably go with an RDBMS.
However, if you only ever needed to query stats by the event then you could make this more document friendly by embedding team stats within each event instead of associating Events and Team via another collection.
By the same logic, if you only ever needed to query stats by the team then you could embed event stats within each team.
How role based ACL should be designed for :
Multiple teams, each team consisting of one manager and multiple members and working from one location. Each location could have multiple teams and there are multiple locations.
Manager of each team could only view/edit data for his team members. A person could also be member of multiple teams, independent of location.
Location_1
-Team_1 -Team_2
-Manager -Manager
-Member_1 -Member_1
-Member_2 -Member_2
Location_2
-Team_1 -Team_2
-Manager -Manager
-Member_1 -Member_1
-Member_2 -Member_2
My thought: I'm thinking of separating it in two parts. Part 1: There should be one group for each team. Maintain table of group membership in database. Part 2: Now, each user can have any role. And ACL could be designed based on those roles. But data would be fetched based on Part 1. this way new teams could be added without change in code. Is this a right way to go?
Kind of a fairly chatty answer here, loose discussion only, no code, at least for now.
Your own model/data structure has to consider members, locations, and teams. I think you have described the relationships pretty clearly, so that should be straightforward. Thinking relationally: a table for team members, including managers; a table for locations; a table for teams with a foreign key into locations and a foreign key into members identifying the manager; a cross-ref table linking members to teams. I assume your member model will have methods for isManagerOfTeam($team), isMemberOfTeam($team), stuff like that. Pretty straightforward.
But much of this is just modeling the relationships, arguably independent of access-control.
For access-control, it appears that location is irrelevant; it's team membership and team management that are the key.
It also sounds like the data you are trying to access-control (what will eventually be the 'resource') will be tagged with a member id, identifying the "owning" member. So, the model for that data might have a method getMember() or even just getMemberId().
So I see some Acl rules that use a Zend_Acl_Assert_Interface instance to make dynamic examinations on the relationships between the role ($member) and those resources:
My_Acl_Assertion_BelongsToSelf
My_Acl_Assertion_BelongToMemberUnderManagement
Then the assert() methods could call the relevant model methods on the passed role and resource to check the team and management relationships.
Like I said, kind of a loose answer, but hopes it helps with some ideas.