As it stands, I have a student table (where each student has a unique row) and an exam table (where each student's exam attempt has a row; the student table is one to many to the exam table).
I want to see if it's possible to add a column to the students table that captures all of the student's exam attempts for a particular exam (as you see below). I was thinking this might require a for loop, but I'm not sure how to do that in QuickBase.
Create a Combined Text Summary field on the Students table for each Exam type.
Related
I have 2 tables on a PBI Dashboard, one that shows Date, Airline Code, Flight Number and Passengers per Flight, and then a table that shows information such as passenger name, date, reservation ID etc.
The first table is filtered to only show flights that have 5 or more people on a flight. Which works fine. I am trying to find a way to filter the second table based on the values that are left in the first table. So the second table should only show the individual traveler records who are on flights with 5+ people. I can't apply a filter with Passenger per Flight, as once I have the traveler information included, it will always be = 1.
Essentially, I want to add a measure into the second table on the right that will NOT take into account the identifiers such as passenger name and reservation ID. It should show the same count for each flight as what's shown on the first table on the left.
I'm sure it's a simple solution, but haven't been able to come to it.
Passenger per Flight = CALCULATE (
DISTINCTCOUNT('Fact Reservation'[TravellerID]),
'Dim TravelType'[Travel Type] = "Air"
)
You simply need a relationship between the two tables that is configured to flow filters from the flight table to the passenger details table.
Using Java and Oracle.
We need to update changes in Email, UserID of employee to third party.
Actual table is Employee and intermediate table we keep which we will use for comparison of changes before sending to third party.
Following are database designs coming in mind for intermediate table:
Only Single table:
EmployeeiD|Value|Type|UpdateDate
Value is userid or email, type will be 'email' or 'userid'. Update date is kept so to figure out that which of email or userid was different and update to third party.
Multiple Table:
Employee_EmailID
EmpId|EmailID|Updatedate
Employee_UserID
EmpId|UserID|Updatedate
Java flow will be:
Pick employee from actual table.
Pick employee from above intermediate table.
Compare differences. Update difference to third party.
Update above table with updated value and last update date.
Which one is consider as best way, single table approach or multiple table or is there any standard way to implement the same? There are 10,000 Employees in system.
Intermediate table is just storing Delta records i.e Records transferred to third party so that it can be compared next day.
Good database design has separate tables for different concepts. Using the same database column to hold different types of data will lead to code which is harder to understand, prone to data corruption and less performative.
You may think it's only two tables and a few tens of thousands of rows, so does it matter? But that is only your current requirement. What you choose now will set the template for what happens when (say) you need to add telephone numbers to the process.
Now in future if we get 5 more entities to update
Do you mean "entities", like say Customers rather than Employees? Or do you really mean "attributes" as in my example of Employee Telephone Number?
Generally speaking we have a separate table for distinct entities, and all the attributes of that entity are grouped at the same cardinality. To take your example, I would expect an Employee to have one UserID and one Email Address so I would design the table like this:
Employee_audit
EmpId|UserID|EmailID|Updatedate
That is, I have one record which stores the complete state of the Employee record at the Updatedate.
If we add a new entity, Customers then we have a new table. Simple. But a new attribute like Employee Phone Number offers a choice, because an employee can have more than one: work landline, mobile, fax, home, etc. So we could represent this in three ways: a child table with a type column, multiple child tables for each type, or as distinct columns on the Employee record.
For the main Employee table I would choose the separate table (or tables, depending on whether I'm shooting for 6NF). But for an audit table I would choose one record per Employee and pivot the phone numbers like this:
Employee_audit
EmpId|UserID|EmailID|Landline|Mobile|Fax|Home|Updatedate
The one thing I would never do is have a single table with type and value columns. It seems attractive because it means we could track additional entities without any further DDL. But in fact it becomes harder to re-assemble the complete state of an Employee at any given time with each attribute we add. Also it means the auditing process itself is more complicated (because it needs to determine which attributes have changed and whether it needs to audit the change) and more expensive (because changing three attributes on the same record entails inserting three audit records).
https://web.stanford.edu/dept/itss/docs/oracle/10g/olap.101/b10333/globdiag.gif
Assume that we have a start schema as above..
My questions is - In real-time how do we populate the colums (unit_price, unit_cost) columns of the fact table..?
Can anyone provide me a start schema tables with real data?
I am having hard time in understanding star schema...
Please help!..
Start schema consists of two types of tables fact tables and dimensions.
The ideal of the star design is that you can split your data in two part.
The static part is described with dimensions and the dynamic part (= transactions) in the fact table.
Each transaction is stored in the fact table as a new record and is connected to the surrounding dimensions, that define the context of the transaction.
The example in link contains two fact tables: SHIPMENTS and PRODUCT_CONDITIONS.
Note that the fact tables in the link are dubbed UNITS_HISTORY_FACT and PRICE_AND_COST_HISTORY_FACT, but I find this not a best choice.
The SHIPMENTS table stores one record for each shipment of a PRODUCT to a CUSTOMER at some TIME, via a defined CHANNEL.
All the above information is defined using the corresponding keys of the respective dimensions.
The fact table also contains MEASURES describing the attributes of the transaction, here the number of UNITS shipped.
The structure of the fact table would be therefore
CUSTOMER_ID
PRODUCT_ID
TIME_ID
CHANNEL_ID
UNITS
The second fact table (bottom) is more interesting, because here you split the product in two parts:
PRODUCT dimension defining the ID, name and other more static attributes
PRODUCT_CONDITION this is fact table, designed with the expectation the price and cost of the product will change over time.
With each change of the price or cost insert a new record in the fact table and connect it to the PRODUCT and TIME (of change).
The structure of the fact table would be therefore
PRODUCT_ID
TIME_ID
UNIT_PRICE
UNIT_COST
Final note the the design of the TIME dimension.
The best practice to connect the fact table with the dimension tables is to use meaningless ID (surrogate keys), but for TIME dimension you should be careful. For big (time partitioned) fact table is often used the natural key (DATE format) to be able to deploy the partitioning features. See more details in How I Defined a Time Dimension Using a Surrogate Key and other resources in web.
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.
SQL Server 2012 MVC3 EF4.3.1 Code First project.
I have a Teacher and Student table with a one to many relationship. The Teacher’s tables Id will be used as the account number so its Id numbering needs to be separate from the Student’s. I would like to create a Person table (containing shared properties such as First, Last, Phone, Email) to reduce redundancy on the properties. Person will also have a one to many relationship to an Address table.
I’ve thought of trying a Table per Hierarchy model with Teacher and Student inheriting from Person but then the Id sets would not be separate and I would have to have a one to many relationship internally on the Person table. I could generate the ID’s through code but is an internal one to many doable or practical?
Another scenario would be to setup Person as a child table with a one to one between and Teacher and Person and a one to one between Student and Person but I’m not sure how or if it’s possible to have two separate one to one’s on a table.
Is there a practical way to do what I want or should I not worry about the redundancy and not use a Person table? If I went that route would it be possible to have two separate one to many relationships to an Address table (Teacher-Address and Student-Address)? Or for that matter a one to many (Teacher-Address, teacher may have an additional shipping address) and one to one (Student-Address)?
Thank you
Another way to do it is to have a one to one between a Person and a Role table. Teacher and Student are merely roles in this arrangement. A given Role can be fulfilled by many Person instances.
You could also do a Person table with an IsTeacher flag.
I can see two possibilities:
One: Go with your Student and Teacher inheriting from a base table of Person and not worry about the 'redundancy'. It's not a redundancy because your relating a Student and a Teacher not a Person to a Person and so in your database and DOM the Person table and Person class know nothing of the Teacher to Student relationship, it only knows that its a person. The teacher and student relationships are stored in there respective types, not the person type. Also, look at Table per Type instead of Table per Heiarchy. It's much cleaner and crisper looking in the database and you don't get all the information of each type in the heiarchy in one table.
Two: Create a table that specifically holds information that both Students and Teachers share and have that related to both the Student and Teacher table separately. You could call it something like "ContactInformation".
Being a teacher and being a student are roles of people, not types of people.
You should have a table for People, a table TeachCourse to say that a Person is the teacher of a course (which in some cases are multiple teachers), a table AssistCourse to say which persons are attending a class as a student. You might have people that teach a course and assist another course, and that wasn't properly modeled in your first version.
You can also create a ContactInformation or ShippingInformation table for People to specify all their data (Some people may have multiple phones, or emails to).