I have a project I'm working on and I want to use MongoDb.
Description:
The programme is a questionnaire for an entity. The entity can be college, faculty or department. A form is captured per year for any of these entities though mostly departments. Queries can be made on any of them. Where needed, the data can be aggregated and used in ranking.
Relationship:
Colleges contain faculties and faculties contain department. Each of them (well departments at the moment has forms). There can be a number of form types (3 at the moment)
Problem:
How do I represent this scenario in MongoDb?
First is the College > Faculty > Department relationship. How do I effectively represent this?
My current thoughts:
1. Concerning the College > Faculty > Department data, I was thinking I could use a single collection and tag them according:
{name:'Department X', tags: ['department'], parent: '???'}
.
The parent could be the id of thee parent element so in this case the id of the associated department.
The other option was
colleges: {name: 'some college',etc,faculties: [{name: 'some faculty', etc, departments: [{...}]}].
The issue was the id I would use to identify each ,eg, department.
For the forms, I'm still not sure. If I embed the data in the department records, how easy will it be to retrieve for a number of departments, say in a faculty and do some sumation on most of the fields (most are number)?
Really need some assistance here coming from a relational background. I'm using c# with CSMongo by Hugo.
Regards,
Richard
Are you sure that faculties can contain department not the college contains the departments?
Also how does a form look like?
Please give me an complete example of one document with a college, 2 faculties, few dept and few forms. That way I might be able to give you some guidance.
Related
Second year CS student here.
Questions:
Is the 'Results' Table currently creating a 'common look-up table'?
How do I solve Employment-student relationship?
Database problem:
For each student they would like to know which degree program they were on (a student may have studies for more than one degree but not at the same time); the modules they took and their final results. For their employment they would like to know the type of employment (Full Time or Part Time, Permanent or Fixed Term, Continued Education, Taking gap year); their job title and whether it is considered a ‘Graduate’ role; The name and address of the employer; a contact email for the student, whether we can use that information for publicity purposes and a brief description of their role.
My current design for Database:
Current ERD
Q1.
I noticed when constructing the ERD there was a ternary relationship between Module, Degree and Student and decided to solve this many to many problem by creating a fourth table called results. It has foreign keys from Module, Degree and Student and contains the Result date and Result score for a student in a module on a degree. Considering each student takes several modules there will be a lot of entries, will 'Results' form a common look up table? I heard these were not best practise when constructing a DB. This design also makes it difficult to query which degrees each student has done (each student can take many degrees just not at the same time). I considered creating separate tables for the Student-Module relationship and Student-Degree relationship however you then would not know which module was taken under which degree.
Q2.
I was given this advice by my lecturer:
The relationship between employment and students it not quite clear and would require some explanation. Typically an employment in the real world is between 1 employer and 1 employee only, not multiple employees per employment.
Student-Employment Relationship
Is this a suitable fix? I currently have a foreign key in student which relates to their employment. Am i still able to use this or am i thinking about this relationship all wrong?
The database should support the following queries:
For a particular student their employment details
Details of students for which they do not have Employment records
Details of students who were unintentionally unemployed within 6 months of their graduation
% of students employed within one year of graduating according to class of degree
% of students in a graduate role for a particular year and degree program
All answers are greatly appreciated. Thanks for your time.
I am just curious why do we need to use one-one, many-one or one-many and many-many in database
It's all about need , in programming we need to maintain data in databases . in many situations we need to create related tables , these kind of related tables connected with relations . for example if you build a application to maintain the user contacts , then you need to design a table for user and contact . here you will be relate both the tables
If you mean, why do we distinguish between cardinalities of relationships, then the answer is that there is no need. All that matters is that we identify & describe sufficient relationships to describe every application situtation.
The cardinality of participation by entities in a relationship is just one property of the relationship. Eg if table EmployeeManager holds the rows where "manager M manages employee E" then it doesn't matter to filling the table whether there is only one manager per employee or one employee per manager; you just look at the world and put the rows that make a true statement from that statement template into the table. Eg Ditto for interpreting a table: the rows are all those that make the statement template into a true statement about the world. You don't need to know cardinalites to query. Eg if table DepartmentManager holds the rows where "manager M manages department D" then EmployeeManager NATURAL JOIN DepartmentManager holds the rows where "manager M manages employee E AND manager M manages department D" whether or not there is only one manager per employee, or employee per manager, or manager per department, or department per manager.
But the benefits are that if we tell the DBMS then it can keep out invalid states, and if we tell users then it can help them understand what the relationship statement templates mean or why the DBMS disallowed a putative erroneous update.
A company database needs to store information about employees
(identified by ssn, with salary and phone as attributes),
departments (identified by dno, with dname and budget as attributes),
and children of employees (with name and age as attributes).
Employees work in departments; each department is managed by an
employee;
a child must be identified uniquely by name when the parent (who is an
employee; assume that only one parent works for the company) is known.
We are not interested in information about a child once the parent
leaves the company.
Draw an ER diagram that captures this information.
I am using "Look Across" Min-Max notation here.
Are the cardinalities between Employee and Department correct?
For instance, is it possible that a Department has zero Employees? Or, is this a relevant information?
Your answer is correct and matches the instructor key for this common example in two different texts that I own.
Other thoughts
Unfortunately most textbooks are poor reflections of reality because they trivialize things, but this is considered necessary when introducing students to complex topics such as modeling reality in a database.
This illustrates problem with creating ERD from English-language narrative which can be ambiguous and open to interpretation, however. Might score some extra points with your instructor if you point that out. In reality, it is not uncommon for employees to work for multiple departments (I do), and for managers to manage multiple departments (mine does). When working with clients it is a good idea to also express the more ambiguous designs with a physical data model (tables and rows) or an actual user interface (form for data entry) so that they are certain of what they are getting.
If a department MUST have a manager and that manager is by relationship working for that department then a department must have minimum 1 employee.
An Employee can (I'm assuming) manage more than 1 department theoretically and a department can also (assumption) be managed by more than 1 Employee.
So I see it like this
Employee *-* Department (many to many relationship)
or in your terms
Employee 1-N Works In 1-N Department
Employee 1-N Managed By 1-N Department
You cardinality is incorrect for the case employee works in department. Since an employee can work in 0 or many departments. Here, the cardinality should be as follows:
employee (0,n) - works in (0,n) departments.
While in the other case department has to have an employee associated with it.
The cardinality in the case department managed by employee is correct in your case.
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'm looking at this company's database design, and would like to know the purpose of their design, ie store relationship in one table and the data in another, why do this?
They have this,
EMPLOYEE
Id (PK)
DepartmentId
EMPLOYEE_DATA
EmployeeId (PK)
First Name
Last Name
Position
etc...
Rather than this...
EMPLOYEE
Id (PK)
DepartmentId
First Name
Last Name
Position
etc...
...OR this...(employee can belong to many departments)
EMPLOYEE
Id (PK)
First Name
Last Name
etc...
EMPLOYEE_DEPARTMENT
Id
EmployeeId
DepartmentId
Position
That's a link table, or join table, or cross table.. lots of different names.
How would you assign an employee to two different departments with your design? You can't. You can only assign them to one.
With their design, they can assign the same ID to multiple departments by creating multiple records with the employee ID and different department ID's.
EDIT:
You need to be more specific about what you're asking. Your first question seemed to be asking what the purpose of mapping table was. Then you changed it, then you changed it again.. none of which makes much sense.
It seems now that you are asking what the better design is, which is a totally different question than what you originally asked. Please state specifically what question you want answered so we don't have to guess.
EDIT2:
Upon re-reading, if this is the actual design, then no.. It does not support multiple department id's. Such a design makes little sense, except for one situation. If the original design did not include a department, this would allow them to add a department ID without modifying the original EMPLOYEE_DATA table.
They may not have wanted to update legacy code to support the Employee id, so they added it this way.
Purpose of design is determined by business rules.
Business rules dictate entity (logical model perspective) / table (physical model perspective) design. No design is "bad" if it is built according to the requirements that were determined based on business rules. Those rules can however change over time -- foreseeing such changes and building to accommodate/future-proof the data model can really save time, effort and ultimately money.
The first and third example are the same -- the third example has an extraneous column (EMPLOYEE_DEPARTMENT.id). ORMs don't like composite keys, so a single column is used in place of.
The second example is fine if:
employees will never work for more than one department
there's no need for historical department tracking
Conclusion:
The first/third example is more realistic for the majority of real-world situations, and can be easily customized to provide more value without major impact (re-writing entire table structure). It uses what is most commonly referred to as a many-to-many relationship to allow many employees to relate to many departments.
If an employee can be in more than one department, then you would need a mapping table but I'd do it like the following:
EMPLOYEE
Id (PK)
First Name
Last Name
DEPARTMENT
Id (PK)
Name
EMPLOYEE_DEPARTMENT
EmployeeId_fk (PK)
DepartmentId_fk (PK)
Position
This would allow for multiple positions in multiple departments.
You would do this if an employee can be a member of multiple departments. With the latter table, each employee can only belong to one department.
The only remotely good reason for doing this is to implement an extension model where the master table identifying unique customers does not include all the data for customers that is not always necessary. Instead, you create one core table with the core employee data and and extension table with all the supplementary fields. I've seen people take this approach to avoid creating large tables with many columns that are rarely needed. However, in my experience it's typically premature optimization, and I wouldn't recommend it.
In contrast to many responses, the model included does not support multiple departments per employee - it is not a many to many mapping approach.