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.
Related
So I am new in designing databases and I'm trying to represent a db diagram for a system where students can rate professors and school. Also Students and Professors can have their account to login.
Is this a proper presentation and am I missing anything as of entity relations ?
And I wasn't sure if i need to use any inheritance as well ..
Enumerated columns are good indication for bad design.
You need an additional table for values.
Once that done, there is no need to separate school rating from professor rating -
use a general rating table containning the id of the rater (which is always a student in your case) and the id and type (school/professor) of the rated element.
I don't see any reason to put students and professors in different tables.
Think of it as a person table with a role attribute.
If a person can be both, than instead of the role attribute add 2 flags columns - is_student and is_professor.
It looks okay but are you sure the relatioship between SchoolRating and Student should be many to many? Wouldn't a rating just have one student (the student who did the rating)?
Also it's not clear to me why SchoolRating and ProfessorRating have so many value attributes.
Initial Review: Seems solid, may require another table or an expansion of SchoolRating.
When you are designing, focus on what your objects accomplish, the questions of facts they answer.
SchoolRating has values that represent the reviews or are they aggregates of a set amount of teachers? How are these reviews rectified with professor rating...or do they have no relation? (They clearly do in a school...so how does your design accomplish this?)
Why does a student have any direct relation with SchoolRating? Should not this table be a true FACT table for the values scored from the professors and/or some rating system?
Why can a student not have multiple teachers or multiple reviews? If a student fails a class but leaves a review...how does your structure rectify a new review from the same student?
Lastly, do not use the inheritance theory in your relational design. It is utterly incompatible with the relational set theory and the sooner you learn to purge that from your system, the better.
Think on terms of DIMENSIONS and FACTS. Think about cardinality, or how you plan to deal with slowly changing dimmensions, whether database columns will provide efficiency.
Concepts like Star-Schema, Snowflake design, of durable keys, natural keys probably should be consulted whenever you question your design.
At the end of the day, what questions your tables can answer and how the system will access these tables are as important, if not more, to the design methodology as it relates to normalization.
I'm curious if there's any way that Microsoft Access or SQL Server can provide a function to show correlation or causation from a SQL Select statement and its results.
This is basically the use case scenario:
Let's say you have two tables, table studentCourseSurveys and table onlineCourseReviews. At the forefront these two tables are mostly unrelated but could be joined based on the course name, for example "ENG 101".
studentCourseSurveys is a table that is intended to hold data that students submit during
their in person course survey at the end of a semester. For example, in the last day of class students receive that form to fill out to rate the instructor based on things such as "exams were related to the actual lecture content", "instructor was on time and prepared", and then at the end they have their short answer opportunities to give additional comments.
onlineCourseReviews is a table that is used by an internal department that conducts content reviews on the online component of courses. For example, this department has individual instructional designers who are assigned different courses in Blackboard to review. They review content, delivery, course structure, and so on and so forth. The course is then given its comments, score, etc.
As already mentioned the tables would be most unrelated. But let's say someone wanted to show a correlation that the results of the online course reviews could somehow indicate that the quality of the overall course was better because of these online reviews, and that this was shown in the responses from the students based on their survey results.(basically, a course that got an online course review score of 10 has course surveys where a great majority of the students rated it as excellent, content was relevant, teacher was prepared, etc, to indicate that an improvement in the online course translated to improvements in the in-person class and overall class quality).
This almost seems like a unique job for a statistician but I'd like to know if it's possible to show this data based on a query in Access or SQL Server. I know that you could just easily join the two tables with a foreign key and then get the results of a survey and online course review in a single statement but that doesn't really say anything. I would think that to show ANY kind of relationship that you need to illustrate a trend over any given period of time.
Thank you.
I would suggest creating a query with three values - course name (e.g., ENG101), the student rating, and the online course rating. In SQL Server you can save the results as a .csv file. Do this, then open it in Excel and use the RSQ function , or R-Squared, to find the correlation coefficient between columns two and three. The closer R-squared is to 1, the closer the two match. 1 mean a perfect correlation. 0 means no relation at all and -1 means related but but in a polar opposite manner.
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.
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.