We have a few different entities. To explain a little better, here is example structure:
We have a lot of students.
We have a lot of homeworks.
Each homework has N (varies per homework) tasks.
There is a junction table connecting students and tasks.
We want to assign some tasks to certain students in a homework. Let's say one homework has 5 possible tasks, we want each student to get one or more tasks.
At the moment, interface lists all students with some properties (for this case let's say - average grade, hair colour, name, gender etc.) and has 5 checkboxes (there are 5 tasks in selected homework). We can use filters to show only students with average grade of 4, or just female students etc.
After a while, you would assign 98% of students, but you notice there are 2% students without any tasks for selected homework (some statistics shows you that). Instead of going through all few thousand students, we'd like to create filter which would use existing filters AND apply additional filter which would show all students which have 0 tasks where task.homeworkId = X
Right now, in my head there is a possible solution, but I'm not sure if this is possible using breeze:
from students
where (OLD_FILTERS)
and ((from junction_table
where task.homeworkId = selectedHomeworkId
and student.id = $parent_query.id).count() = 0)
I've been over this for a while now, can't come up with a nice clean solution. Only thing comming to my mind is pretty complex solution with manual filtering of all student properties and this new condition on server.
Thanks in advance for any help.
EDIT
Tables are related as follows:
student - junction table = 1 to many
task - junction table = 1 to many (basically, it's many-to-many student-task through junction entity)
task - homework = many to 1 (many tasks per one homework)
some perception on the model:
Student:
Id
Property1
Property2
...
Homework
Id
Property1...
Task
Id
HomeworkId // this is foreign key
Property....
JunctionTable
Id
TaskId // foreign key
StudentId // foreign key
Thanks to DenisK for help. We used older version of Breeze without the needed option. Solution is simple predicate:
var pred = breeze.Predicate.create("studentTasks", "any", "task.homeworkId", "==", homeworkId).not();
Related
Consider two tables Foo and Bar and consider models based on them. Now consider a one-to-one relationship between them.
Foo contains has_one :bar in it's declaration so that we're able to access Bar from Foo's objects. But then what I don't understand is why Bar needs a foreign key referencing Foo?
Shouldn't it be easier if they just compare both the ids to get the result?
I'm assuming that there will be problems with comparing both ids and I want to know what the problems are.
The problem with ids is that they store auto-incremented values. Let's consider 2 tables students and projects.
Let's assume a student can have at most 1 project. Which means he can either have a project or not.
Now consider 2 students A & B.
students table
id name
1 A
2 B
now projects table
id name
1 P1
2 NULL
in this case A has a project named as P1 but B doesn't and we're creating a null entry just to maintain and match the id of records present in projects with the students but this is not feasible in the long term. If in a school there are 1000 students then we'll have may be 500 empty rows for 500 students who are not working on a project.
That's why adding a column in projects table is a feasible solution to reduce the size of the table and maintain relationships as well and also if you're going to delete a record then the new id won't be same as the previous one as id's are auto-incremented.
now projects table
id name student_id
1 P1 1
is more feasible and flexible as well. You can make it has_many as well because a student can work on multiple projects as well.
I hope this helps you.
You can't assume that the DB engine will add the same IDs to rows in different tables. You can (I would not recommend) make an app with such behavior and implement it with triggers and constraints, but this would be a very creative (in a negative sense) approach to relational databases.
Suppose the following hypothetical situation where we need two Fact tables defined as:
Evaluation fact table
UserID
SchoolID
CourseID
Status (passed/not passed)
UserResponse Fact table
UserID
SchoolID
CourseID
SubjectID
SurveyID
Response
It's clear that we need a User dimension table, but how would be modelling the another hiercarhy dimension?
The two possible approaches that we have are:
1 - Model all the dimensions separately and relate them to each other (snowflake schema) and relate de fact table to the corresponding dimension. In this case we need multiple joins when build a query.
2 - Following the kimball recommendation, we should unify all 1:n relations in a unique dimension but with this aproximation we should build two dimensions that contain same information but with different granularity:
dim Survey
ID
SurveyDescription
SubjectID
SubjectDescription
CourseID
CourseDescription
SubjectID
SubjectDescription
SchoolID
SchoolDescription
dimCourse
ID
CourseDescription
SubjectID
SubjectDescription
SchoolID
SchoolDescription
Which approach is more appropiate?
Why don't you create your data model like this:
If you have specific questions about how to populate each table, provide sample data, we might help.
Update: According to your question below, you can find answers like these with this model, assuming user is same as student
(added schoolName to dim_school table)
This query below will give you the answer for how many students there are in a school based on the data you have in your fact_evaluation table.
If you ask in general how many students there are in a particular school you need more info like enrollments etc.
select schoolName, count(distinct userID)
from fact_evaluation f
join dim_school d on d.schoolID = f.schoolID
where schoolName = <a school name>
group by 1
I'm working on a project built on Rails 4, ActiveRecord and PostgreSQL and faced with a performance dilemma -
For brevity, let's say I have Category & Item models. Category has_many items.
Let's take the example where category 'Furniture' has 'bed, large mattress, small mattress, armchair', etc. While displaying these items under the category, we would intuitively want to see all kinds of mattresses and bed frames together, instead of being lexicographically ordered. Also, let's assume the total number of items under any category is in the order of < 100 (mostly about ~10-15 per category) & so naturally, the order of items falling in the same 'group' under a category would be much lower than that.
To achieve this grouping, one way is to create a SubCategory model and associate items through them, so we can add items of a certain group later on and still be able to show them together by grouping on the category & sub category.
The other way I'm thinking of, since the order of total items is so small, is to add an order (float type) field to the Item model to still be able to group them together (Bed = 5.01, Mattress = 5.02, Chair = 6.01, Bed Cover = 5.03 & so on).
The only reason I'm considering the other option is because we're confident on the number of items to not go beyond even a 100 in our application's scope and so the Sub Category route - creating a new model and persisting many columns vs one - seems like an overkill for this particular case.
So my question (finally!) is this -
What kind of pitfalls might I fall if I went the second route? Moreover, is sorting on a float field with Postgres an overall better tradeoff on speed and memory vs adding a new model to simulate sub groupings such as mentioned in the above example?
I am in the process of designing this E-R diagram for a shop of which I have shown part of below (the rest is not relevant). See the link please:
E-R diagram
The issue that I have is that the shop only sells two items, Socks and Shoes.
Have I correctly detailed this in my diagram? I'm not sure if my cardinalities and/or my design is correct. A customer has to buy at least one of these items for the order to exist (but has the liberty to buy any number).
The Shoe and Sock entities would have their respective ID attribute, and I am planning to translate to a relational schema like this:
(I forgot to add to my diagram the ORDER_CONTAINS relationship to have an attribute called "Quantity". )
Table: Order_Contains
ORDER_ID | SHOEID | SOCKID | QTY
primary key | FK, could be null |FK, could be null | INT
This clearly won't work since the Qty would be meaningless. Is there a way I can reduce the products to just two products and make all this work?
Having two one-to-many relationships combined into one with nullable fields is a poor design. How would you record an order containing both shoes and socks - a row per shoe with SOCKID set to NULL and vice-versa for socks, or would you combine rows? In the former case the meaning of QTY is clear though it depends on the contents of SHOEID/SOCKID fields, but what would the QTY mean in the latter case? How would you deal with rows where both SHOEID and SOCKID are NULL and the QTY is positive? Keep in mind Murphy's law of databases - if it can be recorded it will be. Worse, your primary key (ORDER_ID) will prevent you from recording more than one row, so a customer couldn't buy more than one (pair of) socks or shoes.
A better design would be to have two separate relations:
Order_Socks (ORDER_ID PK/FK, SOCKID PK/FK, QTY)
Order_Shoes (ORDER_ID PK/FK, SHOEID PK/FK, QTY)
With this, there's only one way to record the contents of an order and it's unambiguous.
You have not explained very well the context here. I'll try to explain from what I understand, and give you some hints.
Do your shop only and always (forever) sell 2 products? Do the details of these products (color, model, weight, width, etc...) need to be persisted in the database? If yes, then we have two entities in the model, SOCKS and SHOES. Each entity has its own properties. A purchase or a order is usually seen as an event on the ERD. If your customers always buys (or order) socks with shoes, then there will always be a link between three entities:
CLIENTS --- SHOES --- SOCKS
This connection / association / relationship is an event, and this would be the purchase (or order).
If a customer can buy separate shoes and socks, then socks and shoes are subtypes of a super entity, called PRODUCTS, and a purchase is an event between CUSTOMERS and PRODUCTS. Here in this case we have a partitioning relationship.
If however, your customers buy separate products, and your store will not sell forever only 2 products, and details of the products are not always the same and will not be saved as columns in a table, then the case is another.
Shoes and socks are considered products, as well as other items that can be considered in future. Thus, we have records/rows in a PRODUCTS table.
When a customer places an order (or a purchase), he (she) is acquiring products. There is a strong link between customers and products here, again usually an event, which would be the purchase (or a order).
I do not know if you do it, but before thinking of start a diagram, type the problem context in a paper or a document. Show all details present in the situation.
The entities are seen when they have properties. If you need to save the name of a customer, the customer's eye color, the customer's e-mail, and so on, then you will have certainly a CUSTOMER entity.
If you see entities relate in some way, then you have a relationship, and you should ask yourself what kind of relationship these entities form. In your case of products and customers, we have a purchasing relationship there between. The established relationship is a purchase (or an order, you call it). One customer can buy various products, and one product (not on the same shelf, is the type, model) can be purchased for several customers, thus, we have a Many-To-Many relationship.
The relationship created changes according to the context. Whatever, we'll invent something crazy here as examples. Say we have customers and products. Say you want to persist a situation where customers lick Products (something really crazy, just for you to see how the context says the relationship).
There would be an intimate connection between customers and products entities (really close... I think...). In this case, the relationship represents a history of customers licking products. This would generate an EVENT. In this event you could put properties such as the date, the amount of times a customer licked a proper product, the weather, the time, the traffic light color on the street, etc., only what you need to persist according to your context, your needs.
Remember that for N-N relationships created, we need to see if new entities (out of relationship) will emerge. This usually happens when you are decomposing the conceptual model to the logical model. Probably, product orders will generate not one but two entities: The ORDER and the products of orders. It is within the products of orders that you place the list of products ordered from each customer, and the quantity.
I would like to present various materials to study ERD, but unfortunately they are all in Portuguese. I hope I have helped you in some way. If you want to be more specific about your problem, I think I can really help you best. Anything, please ask.
Below is an illustration of the kind of data I want to save in Core data. Every city has many schools , every school has many grades and every grade has many students and their details.
I have read a couple of things about Core data and have got it up and starting. But I'm not able to understand how to save an array in core data and is it a good way to do that in the similar case of the illustration?
If i want to save for a particular school an array of total students for that particular grade, would it be a good practice? If yes, is the method provided in this link good to follow?
EDIT : All cities, all schools and all students have same attributes. Whereas each grade has different attributes. So if there are data for 10 grades, there may be 10 types of array for grades.
Also, what if i have a one to many relation between school and students? IE depending on my login i decide whether i need to save school and grades or school and students. How would the relationship be now?
You should use core data with one to many relationship. This would be your entity structure.
UPDATE:
In case you have several grades with different attributes, you can define another entity "GradeType", which contains details of each grades
UPDATE 2:
Let me write down considerations in this scenario.
1. A city can have multiple schools in it, but a school can be only in one city (Branches will have different address ;) ).
2. A school may offer multiple subjects. same subject can be taught in multiple cities.
3. A school may contain multiple students while a student can be enrolled only in one school.
4. A student can register for multiple subjects, while same subject can be registered by multiple students.
5. There can be multiple grades possible for a subject.(lets say 4: A, B, C & D). Similarly, many subjects will follow the same grading system.(A in history, B in Geology etc).
6. A student can have multiple grades. However, the number of grades will be equal to number of subject he/she opted for.
Based on above consideration, this would be your dataModel.
Here Grades Entity will have entries like this:
grade A for physics is scored by these students.
grade A for biology is scored by these students.
…
…
grade B for physics is scored by these students.
grade B for biology is scored by these students.
…
… N So on
Let me know if more info needed.
Dont do it the way shown in that link. Create core data entities for each of them (city,school,grade,student). Add relationship between those entities (Eg: City ->> school which means one to many relationships). Check this link http://www.raywenderlich.com/14742/core-data-on-ios-5-tutorial-how-to-work-with-relations-and-predicates. Refer apple document https://developer.apple.com/library/mac/documentation/cocoa/conceptual/coredata/articles/cdRelationships.html as well. Take your time with core data modelling. Hope it helps