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.
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.
I have a requirement like below:
Department -->> ( has many) employees
Employee -->> (can belong to only one department) Department, no employee can exist without any department.
For setting this up, I have setup the model like
Department
relationships
name: employees
destination: Employee
optional:yes
to-many:yes
delete-rule:cascade
inverse-relationship: none
Employee
relationships
name: department
destination: Department
optional:NO
to-many:NO
delete-rule: No action
Should I create a inverse relationship anywhere in this model?
Have I setup delete-rule for department relationship in Employee right?
Is there anything else I should to get this model right?
Thanks
Yes, you should almost always specify the inverse relationship according to apple's documentation. You've got the option of not doing so, but it should rarely be used.
I think there may be situations where your database can become corrupted if you don't create an inverse relationship, but I'm no expert.
Those two relationships should be inverse relationships of each other.
I'm not sure about the delete rule. Sorry.
EDIT: #jrturton's comment suggests your delete rule is fine.
I am mapping an idea for a relationship using Core Data.
I have an Employer entity who has a many-to-many relationship with Employees. Basically, an employee can work for multiple employers, and an employer can have multiple employees.
The problem I'm facing is, I'm not sure how to manage the contracts between employees and employers.
As an employee can work for either 1 or many employers, they would naturally have a contract for each employer they work for (complete with salary, duration) and a list of dates when they are working for a specific employer.
My question is - how to manage the relationships between Contracts, ContractDates with Employers and Employees?
Thank you.
Image follows.
in the real world you have a contract between an employer and an employee. So why not do the same in core data?
Use a junction table.
That is, the contracts table refers both to Employers and Employees, linking them together. It also contains information on contracts. This way, the contract applies to the relation between employer and employee, which is exactly what you want.
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.