Hello I have the following situation:
I have a product instance table that is nothing more than a product already assigned to a department and employee.
Well, but I have the following business logic: the product can be an equipment, or a component, that is, a product can have children.
thinking how a computer case is a device that has patrimony_code, and has child products (components) such as:
motherboard,
memoirs,
vga
etc etc
and all of these components are connected to the equipment.
I arrived at this with less table:
But I encountered some problems:
my components would not need departament_id, as they do not belong to the department but to the equipment that there belongs to the department.
So I came to this modeling, but I don't know if it is a good thing to do this relationship, could someone help me if there is a more clean / solid solution for this?
if I have understood your description correctly, only a piece of equipment can be assigned directly to a department, not the individual components that make up the piece of equipment?
Assuming this is the case then I suggest you split this problem into 2 separate tasks as they are, in reality, unrelated and trying to treat them as a single model is causing confusion:
Model the relationship between an instance of a piece of equipment and a department
Model the hierarchy of components (and their instances) that make up a piece of equipment
Once you have these two models you can then relate them if you need to but logically they are separate and you can change one without affecting the other
Hope this helps?
UPDATE 1
(in response to your questions)
You construct 1 sub-model that covers your Equipment entity and the Component entity (plus any other relevant entities) that describe how your products are modelled.
Your construct a second sub-model that describes how equipment is assigned to a department.
The only entity that would be (necessarily) common to the 2 sub-models is the Equipment entity; though, obviously, you can display both sub-models on the same diagram if that is required - even though they are logically separate (apart from the one common entity: Equipment)
Related
I'm making a database where I need to create a relationship between 'Modules' and 'Degree' - basically the modules make up the degree - such like:
Module CS 1 is part of Computer Science
Module CS 2 is part of Computer Science
Module PHIL 1 is part of Philosophy
etc.
My table format is as so:
Modules -> Form -> Degree
Modules contains Module Name, and Module ID (PK)
Form contains Module ID and Degree ID (both FK)
Degree contains Degree Name and Degree ID (PK)
I appear to have the issue that regardless, there will be a many-to-many relationship, as there will be multiple Module ID's which correlate to one Degree ID.
Is there a way around this?
This would not be a many-to-many relationship, in fact, that is the entire purposes of the "bridge" table Form.
See the picture below. In the basic ER Diagram (Entity Relationship Diagram, you can read about them here), you can see the following:
There is a ONE-TO-MANY relationship between Module and Form
(i.e., ONE Module ID can appear MANY TIMES in the Form Table, but that Module ID will only appear ONE time in the Module table)
There is a ONE-TO-MANY relationship between Form and Degree
(i.e., ONE Degree ID can appear MANY TIMES in the Form Table, but that Degree ID will only appear ONE time in the Degree table)
Your architecture and usage of a bridge table is indeed one way to eliminate a many-to-many relationship, good job.
I have just started a course on database design and have been given a homework where one of the tasks is to list all the entity types of a fictional hospital according to this pdf: http://docdro.id/mbzdtUg.
I am struggling to figure out what should be an entity type and what should not. I will give you a basic example:
"Staff" is obviously an entity type but each of the staff have to have details regarding their qualifications and work experience. Since a staff member can have multiple qualifications and multiple work experiences these cannot be attributes... right? So should "Staff Qualification" and "Staff Work experience" be an entity type?
According to entity definitions I have read entities should be independent and represent objects that actually exist. What does it mean for an entity to be independent exactly? The "Staff Qualification" and "Staff Work experience" entity types would not exist if the entity type "Staff" didn't exist. Therefore they aren't independent (???) nor do they represent something that exists (physical object). Then what are they if not entity types? Should for example "Appointment" be an entity type? I am really confused... any help is appreciated.
Thanks!
EDIT: Should mention that this should be following a Entity-Relationship model (ER)
EDIT 2: Example 2: A patient can be either a outpatient or a inpatient. Should I make these into 2 entity type or only 1 (Patient)?
Looks like you're on the right track and your understanding is correct. If you foresee that Staff table can have multiple qualifications or work experiences - then qualification and work experience itself should be separated into a different entity table, so should the Appointment.
This is also where the normalization comes into place - because you could have two different staff members have the same work experience (or qualification) - then technically you don't want to just simply have a child table for Staff as that would result in a lot of data duplication. Usually, using normalization principles you would instead create a separate entity table WorkExperience where you would have all your different WorkExperiences. There would be no relationship between Staff and WorkExperiences tables. But you would also create StaffWorkExperiences table (joining table/buffer table), which would be a child of Staff (1:M) , but would also have a constraint to WorkExperiences table (M:1). So essentially you would end up with Staff table linking to StaffWorkExperiences table and the StaffWorkExperiences table in turn linking to WorkExperiences table.
Lastly, if you also have a patient table and the patient can be either outpatient or an inpatient - then that is more like a property and there is no need to have an extra table - so you would have only a patient table and then another column (PatientType or something like that) to describe this particular property.
EDIT
I have added an example schema of how this would look like with a joining table.
Thanks in advance.
I am learning and designing a RDBMS of an organization with 2 departments .
Its pretty straightforward but the problem arises when an action in one department leads to action in the other department . Suppose department one does survey of consumers and this survey causes department 2 to introduce a product. The trouble is I have no idea how to connect this relationships of surveying and introducing new products together. I am learning RDBMS on my own.
I believe you are asking how to model a scenario where you can track a department's actions to the records that they create, whether that record is a product or a survey. I have attached a diagram and will attempt to explain the relationships.
Each department can have a number of different actions. These actions can be shared across departments. Every DepartmentAction can have an associated ActionEntity. This ActionEntity shares a 1 to 0..1 relationship with both Product and Survey. Finally, every product and survey can also have the department's id that created the record.
I just started to work with databases and want to realize the reasons for the concept of adventure-work-db tables design. why do we consider BusinessEntity as a table and we didn't put it in person table? isn't it kind of over-Normalized Table?
A table should generally represent one thing/object/concept. If you were to include the content of BusinessEntity within Person, then the model is saying that a Person is a BusinessEntity and vice versa which I guess is not really true. Although I accept that BusinessEntity does not currently have anything it in other than a reference to a Person.
However the model as it stands is easily extendable. You may wish to add new columns in the future to BusinessEntity (e.g. Company Number, tax registration code). Such attritubes do not belong to a person so would not really belong in the Person table. Hence if your application has a concept of a Business Entity then it is good practice to model it as in your diagram.
I've got a relatively complicated Core Data relationship structure and I'm trying to figure out how to set up value dependencies (or observations) across various to-many relationships. Let me start out with some basic info. I've got a classroom with students, assignments, and grades (students X assignments). For simplicity's sake, we don't really have to focus much on the assignments yet.
StudentObj <--->> ScoreObj <<---> AssignmentObj
Each ScoreObj has a to-one relation with the StudentObj and the AssignmentObj.
ScoreObj has real attributes for the numerical grade, the turnInDate, and notes.
AssignmentObj.scores is the set of Score objects for that assignment (N = all students).
AssignmentObj has real attributes for name, dueDate, curveFunction, gradeWeight, and maxPoints.
StudentObj.scores is the set of Score objects for that student (N = all assignments).
StudentObj also has real attributes like name, studentID, email, etc.
StudentObj has a transient (calculated, not stored) attribute called gradeTotal.
This last item, gradeTotal, is the real pickle. it calculates the student's overall semester grade using the scores (ScoreObj) from all their assignments, their associated assignment gradeWeights, curves, and maxPoints, and various other things.
This gradeTotal value is displayed in a table column, along with all the students and their individual assignment grades. Determining the value of gradeTotal is a relatively expensive operation, particularly with a large class, therefore I want to run it only when necessary. For simplicity's sake, I'm not storing that gradeTotal value in the core data model. I don't mind caching it somewhere, but I'm having a bitch of a time determining where and how to best update that cache.
I need to run that calculation for each student whenever any value changes that affects their gradeTotal. If this were a simple to-one relationship, I know I could use something like keyPathsForValuesAffectingGradeTotal ... but it's more like a many-to-one-to-many relationship. Does anyone know of an elegant (and KVC correct) solution? I guess I could tear through all those score and assignment objects and tell them to register their students as observers. But this seems like a blunt force approach.
I just postet a project on github which probably solves part of the problem with observings
http://github.com/mbrugger/CoreDataDependentProperties
A more detailed description of the project can be found there.
-(NSArray*) keyPathsForValuesAffecting would not have solved your problem as this only works across to-one relations
In addition you should not make the dependent attribute transient, as it makes your context "dirty" (unsaved changes) already after recalculating all values after loading