Consider the following relational schemas (primary keys are in bold):
staff(staff id, name, monthly salary, address, phone number, role id);
role(role id, role name, role desc);
patient(pat id, pat name, pat address, pat contact, pat blood type);
appointment(date, time, staff id, pat id);
How do you write the list of names of ALL patients who had SEPARATE appointments with DIFFERENT doctors in relational algebra?
N.B. this is a question taken from exam revision that I'm stuck with!
P.S. a doctor can be found by selecting role_name="Doctor"
I'm not sure about relational Algebra but in relational calculus, it would give:
yet, there is a mistake on the time constraint as far as here we will never be able to have an appointment at the same time either in one day or in two different days: for instance having an appointment on Monday at 1200 and the Tuesday at 1200 is forbidden here.
I will try to correct it and do in relational algebra and in SQL tomorrow if I have the time.
Good luck, though.
Related
This is kind of an odd situation and I am pretty new to RLS so please forgive me if what I am asking about here might seem a little silly. I am trying to create Row Level Security for a School District. I have a table that has the different schools codes, employee IDs and their position. I have another table that has the employee ID for teachers and their Teacher ID along with the ID if the students they have for the current year with a separate row for each bell period.
I have tried to create a bridge table that contains the Employee ID, Teacher ID as well as the School Codes and connected it with the other two tables.
For testing purposes, I am trying to connect it to the students basic information and set security to see how to give teachers access. I feel like I am almost there but I might be missing something out in here.
Can you please tell me how to go forward from here. Thank you
Given These Schemas:
Account: bname, acct_no, balance
Depositor: cname, acct_no
Customer: cname, street, city <-(all customers / both loan and account customers)
Loan: loan_no, amount, b_name
Borrower: cname, loan_no
Branch: bname, b_city, assets
Question: Find branches whose customers include all customers that live in Tulsa
My professor gave this solution:
Π cname, bname(account ⋈ depositor) / Πcname(σcity == ‘Tulsa’ (customers))
I don't think the part Π cname, bname(account ⋈ depositor) is correct
because that ONLY includes the cname and bname of customers with accounts and does not include ALL customers (leaves out those with loans). The question does not specifically say "Find branches whose customers with accounts include all customers that live in Tulsa".
What am I missing?
We can guess--per names, symmetry & your mention of "loan and account customers"--that there is a correct query involving (the union of projections of) (Account join Depositor) & (Loan join Borrower). So it seems like your take on a query is reasonable. But you don't give the base table predicates (criteria under which rows appear); you rely on us to guess.
Under constraints some queries return the same results as others that otherwise wouldn't. Maybe your professor thinks that (it is obvious that) a borrower must have an account. Under that constraint, if your take is correct then so is theirs. Without certain constraints like that, you are right that they are wrong. But you don't also give the constraints.
However you are presumably both wrong: If a certain branch & Tulsa have no customers then the result should hold that branch. But a quotient will not. The specification is only similar to one corresponding to a division. Your division returns "branches whose customers include all customers that live in Tulsa" and that have at least one customer. This is a case of classic errors & ambiguities in specification & implementation involving division & almost involving division. On the other hand, maybe there is a constraint that no bank has no customers. Then your query is correct--but not your reasoning.
Re relational querying. (Which you can use to justify your query & arguments precisely & soundly.)
On the relational algebra exam I had yesterday there was a question I couldn't answer and want to know how it would be solved. The constraint on the question was I wasn't allowed to use aggregate functions which I found difficult. The schema is as follows.
EMPLOYEE = {id, name, phone} with id PK
COURSE = {course_no, title, subject} with course_no PK
COMPLETED = {course_no, student_id, grade, semester} with {course_no,id,semester} PK
The question went: List the pairs of employees who have completed the same courses and have always completed these same courses in the same years and have never received grade 'D' in any of these courses. List each pair?
If any could shed some light that would be great.
Basically, you first build a query that joins the tables together to form the desired list of properties per employee.
Then you copy those two queries and join the results on course_no and - I guess - semester (and remember to exclude the rows where the same employee id appears on both sides).
Finally you filter this result by grade.
There are other variations possible, but this is the general idea.
I'm assigned to make a web based survey application on ASP.NET MVC3.
And I have three different surveys. I have to the way best way to store survey answers on database. I'm came up with only one solution: To make an answer table for each survey type.
Can you suggest better solutions?
You can have single table itself for Answers with Survey type as a Column.
perhaps something like this?
table survey_answers
id (this is the pk) : qid (question id): answer (varchar MAX) : pid (person id)
what you can do with this is make a questions table, a person table. in the question table, put the qid, the question, and the group of questions it belongs to (the survey id). Persons table is obvious, you put a pid (person id) and info about the person (such as name, age, gender etc.)
the reason that a three table approach is bad is because let's say the amount of surveys you have grows. let's see it becomes 100 different types of surveys or more - which is a definite possibility depending on where you work - are you going to have 100 different tables? 1000? no way.
Here is the scenario: (MySQL 5.1+, PHP, Apache)
I am planning a SaaS application that will let CLIENTS visit SHOPS and book TRIPS. (ALL CAPS are entities). SHOPS offer TRIPS but they only have a certain number of EMPLOYEES to guide the TRIPS (a transactional record). Essentially it is an issue of managing a daily capacity for each SHOP based upon the number of available EMPLOYEES. What is the best DB design solution for delivering this functionality in a way that incurs the lowest amount of overhead?
Here is a simplified view of the database entities:
table.clients
client_id (pk, ai)
table.shops
shop_id (pk, ai)
table.employees
employee_id (pk, ai)
shop_id (fk)
table.trips
trip_id (pk, ai)
client_id (fk)
shop_id (fk)
trip_date (date)
SCENARIO 1
I could run a query on TRIPS for every request when a user wants to view the calendar, like:
SELECT COUNT(*),
trips.trip_date,
trips.shop_id
FROM trips
WHERE shop_id=1
GROUP BY trips.trip_date, trips.shop_id
SCENARIO 2
Create a summary table that stored info on every day but this strategy seems nightmarish with overhead issues. For instance, imagine that there are 1000 shops each booking 1000 trips per 365 day year and the table should store info for the next 2 years (830 days). It seems like that would 1/ create a huge summary table (830,000 rows) that would 2/ be queried 1,000,000+ times per year (1000 shops * 1000 trips per shop). When a CLIENT booked a TRIP it would increment the number (or when a trip was cancelled the number would decrement) which would effectively create a daily inventory/capacity.
So, my question is this: Which method is the best? Or is there a better way to accomplish this?
Thanks!
Sounds like fun!
Firstly - I know you've given us a simplified version of the schema, so I assume there's a lot more elsewhere, but your "trips" table looks wrong - if shops have one and only one client, you don't need the client ID in the trips table.
However, you do need a "booked_trips" table, to record which trip is booked to which employee - you could store that against the "trips" table too, but typically a booking has lots of other stuff like an invoice, a booked date etc. so you may want to separate those things out.
I'd recommend something like your "option 1"- use queries to derive data stored in normalized tables, rather than option 2, which is effectively a denormalization for speed.
It's worth defining "overhead" in your question - pretty much all of these design questions trade time versus speed; if by overhead you mean disk space, you get a different answer than if you mean "time to run my queries".
Generally, my advice is to work with a normalized approach and measure performance; only denormalize if you know you have a problem.