1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Hi Guest, welcome to the TES Community!

    Connect with like-minded education professionals and have your say on the issues that matter to you.

    Don't forget to look at the how to guide.

    Dismiss Notice

Applied ICT Unit 7 6957 June 2014

Discussion in 'Computing and ICT' started by chrishammond38, Mar 13, 2014.

  1. Hi

    Just wanted to set up a thread to collate ideas and information about the forthcoming pre-release for 6957 Unit 7.

    Any predictions or expected similarities to previous papers etc...

    Feel free to post anything useful to those of us teaching it.
     
  2. Since moving schools I am now delivering this unit again after three years of avoiding it.

    It's like a bad penny that keeps popping up.
     
  3. DEmsley

    DEmsley New commenter

    I used to love this unit. I'll miss it. I'll be keeping an eye on this thread though.
     
  4. I guess we shall find out tomorrow? Can't wait to endure another year of 6957, would be interesting to see if things change with the demise of modular exams
     
  5. I have what probably is a very simple question for the experts out there but I am only a lowly Geography teacher!

    In a scenario that has 5 tables (e.g. June 2012) and two text files to import how do you get your students to setup the tables and import the data as the method I use (analyse table wizard) does not work if there are two source data files.
     
  6. Import them and then use append queries
     
  7. ICTgeek

    ICTgeek New commenter

    I don't mind this unit but todays scenario seems a bit confusing. Usually I can break it down into tables without seeing the data.

    What does everyone else think?
     
  8. longtooth

    longtooth New commenter

    It isn't nice. I can see lots of problems already. I have only looked at it for twenty minutes so I am sure that this will change but initial thoughts ar four tables.

    TblStudent(Student ID,First,Surname,Gender)

    TbJob(JobID,Job_description,Maxnumber)

    TblProduction(ProductionID,ProductionName)

    TbljobRoles(StudentID,JobID,ProductionID)
     
  9. ICTgeek

    ICTgeek New commenter

    tblStudent will have preferred role in too, I think.
     
  10. longtooth

    longtooth New commenter

    it shouldn't as its not wholly dependent on studentid.
     
  11. ICTgeek

    ICTgeek New commenter

    Oh, just in the scenario it says "students specify the production job they would like to have" so I figured there'd be a search done on which students prefer which job.

    Also in the Registering Students section it says "ensuring their name, gender and preferred production job are present"
     
  12. What about tblJobRoles(ProdID,StudentID,JobID) because a student can only have one job?
     
  13. I love/hate this Unit too and this one does look tricky. Agree with tables longtooth but think Characters will be a separate table. This may mean Assigned Characters separate too. My Initial thoughts but seems too messy at the moment

    TblStudent(Student ID,First,Surname,Gender)

    TbJob(JobID,Job_description,Maxnumber)

    tblCharacter(Character Name, Description, Number Required)

    TblProduction(ProductionID,ProductionName)

    TbljobRoles(StudentID,JobID,ProductionID

    TblCharRoles(StudentID, CharID

    Relationships (One-to-many)

    TblProductions - tblcharacters

    TblProductions - tbljobs

    tblStudents - TblJobRoles

    TblStudents - TblCharRoles

    TblCharacters - tblCharRoles

    TblJobs - TblJobRoles

    Any advice/improvements gratefully received
     
  14. A little bit of vagueness regarding whether we are dealing with assigning students to jobs for productions or performances - is the assumption that a student undertakes their role in every performance of a production?

    Note how task 3 states how 'characters that still need actors for the current PERFORMANCE'.
     
  15. ICTgeek

    ICTgeek New commenter

    So far I've got

    tblStudent(StudentID, StudentFirstName, StudentSurname, StudentGender, StudentPreferredRole)

    tblStudentRoles(StudentID, PerformanceID,RoleID*)

    tblPerformance(PerformanceID, ProductionID*, PerformanceDate)

    tblProduction(ProductionID, ProductionName)

    tblRoles(RoleID,RoleDescription, MaxNumber, RoleGender, RoleCategory ProductionID*)

    With RoleGender, I would use the validation of male, female and n/a for roles with could be either and with RoleCategory and StudentPreferredRole, I'd do a choice of Actor, Directing Crew, Sound Crew and Lighting Crew)
     
  16. The last sentence of the second paragraph states, "They will keep the same job on all productions they are involved with."

    I take this to mean that an actor will only be able to be a character, and sound tech will only ever be a sound tech.
     
  17. p1ppaj

    p1ppaj New commenter

    That is my understanding also AmosMac
     
  18. longtooth

    longtooth New commenter

    They will also need to record in production table the type of performance, whether it?s for fun or A level assessment.
     
  19. belch

    belch New commenter

    Slightly confusing to start with but I think its four tables too

    TblStudent(studentid, Gender, PreferredJOb),

    tbljob(jobID,jobtype,CharacterName,NoofJobs),

    tblproduction(productionID, productiondate,productiontime)

    tbljobroles(STudentID,JobID,ProdcutionID

    There is only one production with many performances, a student has to do the same job in all performances

    • updating any records as necessary.- this make me think that we need to reduce the noofjobs as they are taken.
     
  20. This is a lot more difficult that some of the previous years but has some similarities to the Run Club in my opinion. The trick is with the exam as difficult as it may seem is not to overcomplicate the solution as we have fallen foul of this in the past. So far I have the following ideas:

    tbl_Student

    tbl_production

    tbl_characters

    tbl_cast

    tbl_Roles

    The idea I will try out is that the tbl_Cast is the composite table with links to the Student/ Production / Characters / Jobs. All it contains is the primary key links and another field (YES/NO) to identify that it has been filled

    One Student to Many Cast Roles

    One Production to Many Cast Roles

    One Character to Many Cast roles (in the case of the winged monkeys)

    One Job to Many Cast Roles

    The idea behind this is that for each production there will be many characters and possible many characters for each role. The CAST table will be large but will be the only data that needs to be populated with a tick (Yes/No field) on the 2nd form, just like the results on the Run Club 2 years ago. I will try to create the system and see where I get from here
     

Share This Page