I need to "Display all the columns of Employee for those employees who invoiced a vehicle that was owned by a dealership that is different than the dealership that the employee works for."
I'm not allowed to use joins to answer this question so I'm a little confused as to how to get all the information from these tables. I'd need to see if an employee invoiced a vehicle, then determine which dealership that vehicle is sold at, then determine if that dealerships id code is the same as the employees id code.
What are some possible alternatives to using join.
Invoice, Employee, Dealership, and Vehicle are each their own table.
Nested statements are a possible alternative.
select * from Employees e
where employeeID is in
(select ieid from Invoice
where ivin is in
(select vehicleID from Vehicle
where vdcode <> e.edcode))
Related
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
Lets say a relationship is described as:
A company has many employees
A company has many departments
A department has many employees
So, something like this;
Company -<< Departments >>- Employees
If department table has a basic structure of:
// Pseduocode
company_id // Foreign key
department_id // Primary key
[employees] // Array or collection of employees
If we go back to this phrase;
A Company has many employees
Does this mean that the employee table needs or requires a reference for the company_id too?
So, Employee would be:
employee_id
company_id // I'm not sure if this is requried or not
department_id
I'm intending to hopefully abstract this data into a contracts table in case of employees are freelancers/contracters, etc or have multiple employees.
But for now..
My question is:
Does my employee table require a reference to the company table, or is the company reference implied via the department table?
Many thanks
Question is: do you need a straight connection between Company and Employee? If you do, add it, if not then yes, the connection is implied through Department.
EDIT:
Technically, your Department table does not need a list of Employees. Each row of Employee table has a reference ID to Department, that's enough.
Check this out for more information.
The relationship is implied through the department, so you don't conceptually need it. Adding it, would be an example of denormalisation, and would allow inconsistencies to crop up. For example, you might have company_1 with department_1 and company_2. Now employee_1 might be linked to department_1 but company_2, because of some flaw/bug in the application code. There's no way to express this constraint as a SQL schema, so you'd have to go with more complicated stuff such as triggers, or application code checks etc.
However, sometimes you only need info about companies and employees, but not about departments. If it's really performance critical, doing the extra join with departments in order to find the company for an employee or the employees for a company might not cut it, so you'll just have to live with the denormalisation.
You probably do not need to link Company with Employee. The relation between Departement and Company already do the job. You may need it only if there are existing particular cases requiring this relationship.
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.
I'm a bit confused on what a many to many relationship is. I'm wondering if the following is a many to many relationship:
A student at a school has many clubs. A club at a school has many students. Let's say that the student has many attributes: firstname, lastname, phone, age, email, etc. A club only has one attribute: a name.
When I make a new club, I want to be able to give the club a name and one or more students. Upon making the club, I want that club to be associated with those students and those students to be associated with that club.
When I make a new student, I want to be able to give the student a firstname, last name, etc, and one or more clubs. Upon making the student, I want that student to be associated with those clubs and those clubs to be associated with that student.
I also want to display a club's students and a student's clubs on their show pages.
I've read that a many to many relationship is when you have a join table that lets you access common attributes of the resulting students and clubs, but there are no common attributes in my case.
Do I have a many to many relationship here? If so, do I use a HABTM or has_many, through relationship?
Actually yes you DO have common attributes.
You stated yourself that a Student has many Clubs
And a Club has many Students.
What is in common? Students and Clubs.
What now follows is to define what a Student and a Club actually are, which you already did.
A Student is a combination of firstname, last name, etc... What you have not specified is what makes a Student UNIQUE. A club also must be defined as to what will make it UNIQUE. While for academic purposes, you could say the name is what makes it unique, in real live, that would probably not be the best solution.
Usually for performance purposes, each student is given a unique Autoincrement ID (which is a number).
Same thing can be done with the Club.
You create a 3rd table which is what creates the Many to Many relation.
In that 3rd table, you have 2 columns. One with the Unique Index for the Student, and the other column with the Unique Index for the Club. You simply add an entry on that table in which you wish to relate a student to a club.
Since you can have many students assigned to the same club, and you can have many clubs assigned to the same student, you have a many to many relation.
Edit: As mentioned in another answer, your 3rd table should also declare the combined indexes as unique, so that you don't add the same entry multiple times.
You have a many to many
Create an id for each table that is unique for that table typically an auto incrementing int.
Then a third table that is a junction/intersect table call it X.
Put a row in X with the student id and club id if the student has the club and vice versa. It would have a unique composite key in table X across both id's in it.
The composite would guarantee no duplicate rows in X
Yes indeed there is a many-to-many relationship here, use HABTM. Also, why do you say that there are no attributes in common? Club names and student names are definitely common attributes in this case.
I'm trying to figure out what the best (most logical) way of designing this database for an app that will allow a user to CRUD to-do tasks (more or less), however, they're organized into hard-coded categories.
So let's say you're about to go to your favorite department store. You need to hit up the Women's floor and pick up your girlfriend the shoes she ordered, and the matching dress (which is on the completely other side of the store, but on the same floor.) Then, you need to go to the Boy's department for your little brother, and pick up two different pairs of shorts, one pair of pants, and a new pair of shoes.
The Women's Floor and Boy's Department are two examples of categories that the shopping list items will fall into.
So it looks like this:
* Women's Floor
1 Pair Shoes
1 Dress
* Boy's Department
2 Shorts
1 Pant
1 Pair Shoes
So my database design could look like so...
Categories: id, title
ListIndex: id, user_id
ShoppingList: id, listindex_id, category_id, item_id, order, active
Items: id, name, category_id
Categories would be Boy's Department, Women's Floor, etc. Users would not be able to create new categories, but instead, we would predefine the categories
ListIndex would provide a master relation to the shopping list as a whole.
ShoppingList would be the actual shopping list (active would be 0/1, so the user could have a way to remind themselves that they bought the item / put it in their cart.)
Items would have a list of items that are available to put into the to-do tasks. We would categorize these ourselves on the back-end.
Is this the right way of doing it?
Hopefully i understood the description of the problem correctly but i was thinking here's one way you could lay your database and models out. I also don't think you need the ListIndex:
Database Tables
Categories: id, title
ShoppingLists: id, user_id, order, active
Items: id, title
ShoppingListItems: id, item_id, shopping_list_id, quantity
CategorizedItems: id, category_id, item_id
Users: id, name
Models
User:
has_many shopping_lists
ShoppingList:
belongs_to user
has_many shopping_list_items
has_many items, through shopping_list_items
Items:
has_many categorized_items
has_many categories, through categorized_items
(optional: you could query an item for the shopping lists that it is on)
has_many shopping_list_items
has_many shopping_lists, through shopping_list_items
Categories:
has_many categorized_items
has_many items, through categorized_items
My thinking is this --
Individual categories are basically static, that's pretty straight forward.
Shopping lists represent a User's (via the user_id) list of items that will be purchased. The link between an item and a shopping list could take place in a join table called ShoppingListItems where each row links together the relationship between a list, an item, and the quantity.
Items are interesting because in your example an item is something that can actually be in multiple categories. i.e. "pants" can be in boys/girls/men/women and probably pets :(. To support that I think you can use another join table called CategorizedItems that basically lets you query for "items in a particular category" or "categories an item is in".