Currently I have a situation whereby 2 weak entities form an associative entity (Due to a many-to-many relationship).
"Project" Strong Entity consist of
projectID (PK), projectName, projectStartDate, projectEndDate
"Task" Weak Entity consist of a
composite primary key projectID (FK,PK) and taskID (PK), taskName,etc
"Resource" Weak Entity consist of a
composite primary key projectID (FK,PK) and resourceID (PK), resourceName, maxUnits, standardRate, costPerUse, etc
(resource entity is like manpower/equipments/machineries. However, each resource to each project varies, hence I feel that it cannot be a standalone entity but it has to be a weak entity associated to "Project" entity.)
However, 1 resource can have many tasks in a project, and 1 task can have many resources. Therefore it formed a many-to-many relationship. (between Resource and Task weak entities)
Hence, it has an associative entity called "Assignment" entity.
If I were to map out the "Assignment" table, it would have these attributes:
projectID, taskID, resourceID, workCompleted, work, units
Afterwhich I'm confused, when I create the SQL structure for "Assignment" table, do i reference projectID from Task Weak Entity, or from Resource Weak Entity?
Or am I mapping everything incorrectly?
Well - this will be difficult to actually answer in full, because a lot of it depends on your actual data and datamodel etc.
From what you mention, I would think you need a Resource table that's not associated to the Project, because if it's staff / manpower - one staff member should be able to be associated to multiple projects (I would think) making it a many-to-many association between "Staff" and "Project".
So firstly - I think you would need a table structure like this:
Staff/Resource --> ResourceOnProject <-- Project
Id (PK) --> ProjectID, ResourceId <-- Id (PK)
instead of your existing Resource table.
If this is possible, I think it should help you onwards.
Depending on information in tasks, you might be able to to the same for that.
But now, you'd should have the possibility to change your Assignment to just hold ResourceId from Staff/Resource without the need of the "double" ProjectId problem you're faced with in your current setup.
So basically:
Staff/Resource (Id PK)
Project (Id PK)
ResourceOnProject (ProjectId FK, ResourceId FK)
Task (Id PK, ProjectId FK)
Assignment (TaskId FK, ProjectId FK, ResourceId FK)
Related
My understanding is that there is a ParentId in CutomerAddress which will be either the AccountId or ContactId. Also, the Account entity has an AddressId.
How does the relationship flow between Account and CustomerAddress? Is the Account referencing CustomerAddress?
If I create a new Account/Contact that has the same CustomerAddress of a previously existing Account, will the same AddressId be used or a different record will be created in CustomerAddress for this Account/Contact? Usually, at least the Telephone number column will be different which will result in creating a new record but if all fields are similar will a new CustomerAddress record still be created?
No, CustomerAddress records cannot be shared. The relationship between Account : CustomerAddress and Contact : CustomerAddress is 1:N. There is no N:M intersection.
It makes it simple to understand, but the downside is we may end up with quite some duplicated data.
I have searched on the net but was not able to get an answer for my case. I am migrating a project on doctrine.
What is the correct way to link an entity to another entity that contains all the "families" of a project.
The families can be for instance :
"project_status" : status1, status2, status3
"countries" : en, us, cn ...
"tags" : tag1, tag2, ...
So all these values are stored in the same table in database and my entity handle this.
So now i have an entity that can have for example several countries or tags.
In the database i have one text field for the countries and one text field for the tags. And i store the ids of each tag or family inside these fields.
So let's say that I have one entity called "family" and one entity called "myEntity".
What is the best way to do ?
Ok maybe I have found one way in fact.
Instead of using my usual text field in my entity table to store the ids of the families I will use a join table.
So let's say that I have one table with my different lists in my project (country, file_status, and other possible lists). I will then have one entity for this table "familyEntity".
I will create a table that will be used for the cases in which one entityA can have several values of the same family (country for instance). In that case, I wil have a many to many association between familyEntity and entityA for that family.
If I have another entityB that uses the family "status" with several values possible, I will also have a many to many association using the same table for the association.
In the other cases in which only one value is possible for one family I will have many to one association.
Don't know if it is the right way but it occured to me that way. This solution seems ok for primary keys that are not compound).
I am trying to implement an entity relation for a hospital oracle database system.
I am rather confused if I should seperate the table below or merge them into 1.
- Supply
ItemNo (PK) , Name, ItemDescription, QuantityInStock, BackOrderLevel, CostPerUnit
- PharmaceuticalSupply
DrugNo (PK) , Dosage, MethodOfAdmin
Basically in my ERD, I pointed PharmaceuticalSupply to Supply as a subset which inherits the attribute but also have additional attributes. Am I wrong in doing that?
Ultimately, this is a design decision that has no right or wrong answer, but keeping them separate can be helpful. For example, there are many types of supplies that are not pharmaceutical. If you merge the tables, you make it possible to enter data that has no real meaning. For example, you can't have a dosage of bandages. The separate table makes it clear that dosage only applies to pharmaceuticals.
Note that there are a few variations on how to manage the PKs and FKs in PharmaceuticalSupply. It could have both an ItemNo and a DrugNo, where ItemNo is a foreign key. In that case, either one could be the primary key, but if DrugNo is the primary key, then ItemNo probably needs to be a unique index. However, unless DrugNo is needed due to some custom format, it might work well to simply use ItemNo as both PK and FK and completely eliminate DrugNo. This results in a "specialization" as the relational database world likes to refer to it.
It depends on your population. It it's a subset, to reduce redundancy add a foreign key to Supply. That way you'll be able to build a join that list all data.
I would still introduce a DrugNo key for indexing. Can an item number appear more than once in the PharmaceuticalSupply table ? If your do then your definitely need the DrugNo key.
PharmaceuticalSupply
DrugNo (PK) , ItemNo (FK), Dosage, MethodOfAdmin
What's the best way to handle this scenario?
I have a customer Model(Table) contains contact info for customers
I have Prospect Model(Table) contains contact info for store visitors that aren't customers
I have an Opportunity Model (Table) when either a customer or Prospect visits the store.
In my view I want to generate a new oppportunity. An opportunity can only contain either 1 customer association or 1 prospect association but not both.
In my opportunity model I currently have both the customer and prospect as nullable foreign Id's and and navigation properties. I also have an ICollection<> for Customers and Prospects on the opportunity model.
Is this the right way to do handle a conditional association?
When it comes to the view, I'm stuck on how would I make the customer or prospect association?
I am a computer science student, and this is my understanding on DB relationships:
Since you have two types of "People" - Customer - and Prospect - you could potentially have a table called "Person". In the Person table any common data among both entities would be stored (FirstName, LastName, Address1, Address2, City, State, Zip, etc...).
To indicate that a Person is a Prospect, you would have a Prospect table, which would have a PersonId to link to the person table. You can store more specific attributes about a prospect in this table.
The same would go for a Customer - you would have a Customer table - that would have a PersonId column to link to the Person table, and any specific attributes for the Customer entity.
Now you have a database in which you can derive other entities ... say an Employee entity > you have your base Person Entity to start from. And your Employee table would link back to it, and also have other custom columns for employee specific data.
Does that make sense?
Or maybe I'm going about this all wrong :). Please correct me if I am wrong as I am still a student.
I think you are stuck because you now have two fields on an "Opportunity" record (Customer OR Prospect), one of which MUST be null. With the model I proposed, your Opportunity would link to a Person, in which you can define custom business rules restricting say... an Employee Opportunity (which actually might not be a bad idea).
For the referenced Person in your Opportunity model, it would not be an ICollection (since you specifically said that an opportunity can have ONLY one person). It would simply be a single class such as:
private virtual Person Person { get; set; }
EDIT: If you don't want to restructure your entire database, you could just have a dropdown that asks what type of Opportunity this is (Customer, or Prospect). Based on the selection, you would add a foreign key in your Opportunity table to link to your [Customer or Prospect].
I have an entity that has a 1-to-many relationship with another ( Entity Position has One Department).
In the details view I'm showing in s combobox a list of all the departments available and I want to start the selecteditem in the combo is the department to which the entity is related.
The problem is than I am using layers so the Position context it is different to the context of the list of departments and when I do something like:
comboBoxDepartments.SelectedItem = Position.Departament
does not work, how can I make a comparison of the items of an entity with a different context?
If the entities have a unique identity, then compare the identity. If there's another unique column (name, for instance) that is NOT NULL, then you could compare that.
Otherwise, see https://stackoverflow.com/search?q=Compare+2+Entities.