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. Yeah, that is along the same lines.
     
  2. Just to get opinions on a slightly different table structure. Most people have mentioned the job or roles table which will contain the job id, type, gender and number required. Now this will have to contain the characters for the performance, but no one seems to have put performance id in this table which would be required as the different productions will have different characters. Could this table just become a characters table that contains:

    productionid, character id, gender, number required. You would not require type as they are all acting jobs. In the main link table you would only require pupilid, production id, character id, Assigned. You would not need to store job id as it is already in the pupil table.

    The structure could look like this

    PupilTBL: Pupilid, name, Gender, job

    ProductionTBL: Production id, name, type

    Character TBL: Production id, character id, gender, number required

    Cast TBL: Pupil id, Production id, charcter id, assigned

    You would then be able on your task 2 form to select the production get the details of the character if the pupil is an actor.

    My question would be should the non acting roles be lumped in this character table and then have to include the job type or is it just the characters that are important in terms of numbers/gender?

    please let me know if this is wrong in some way as it is late and my brain now hurts after looking at this
     
  3. I know what you mean about it being too complicated an the "suitable actor / suitable student" section is underlined in red on my copy but I have come up with a working solution based on the 2 sub-form solution. My solution takes the student ID and production job from the add student form created in the previous activity. I have then made a query which looks up whether the student is an actor, director or sound (only 3 I've added so far) and used this to populate a subform. I have then used a slightly different subform with less information for production jobs...

    I will tweak my model tomorrow and see if I can get all this working off one subform now I have it in 2.

    I love this exam - honestly! [​IMG]


     
  4. There is a possibility that everybody may be overthinking this. We need to remember that traditionally Unit 7 will be a 4 table structure. With all the changes in the subject at the moment, Edexcel are unlikely to be throwing curveballs. I'm sure many of us are looking at new courses and some might even be doing this for the last time as we look to offering our 6th form new CS courses.

    As such - I really doubt we are dealing with a 5 or more table structure. I did ring and ask for clarification on the use of the terms 'production' and 'performance'. They promised a callback but got none.

    Characters and production assignment will surely be done in the same way. Visable properties on the assignment form could be used to display fields relevant to characters if actor is the

    The checking process can easily be done with a macro linked to the save button on the assignment form

    Regarding whether we are dealing performances or productions I'm convinced it will be performances. My reasoning:

    1. Only is one production - seems pointless having a table with only one record - Extending or ammending for future productions sounds like good evaluation fodder

    2. Dorothy ain't in Grease or West Side Story, so allowing the system to assign that character to other 'productions' doesn't make sense.

    3. I played with considering this and the structure gets too big - not typical of Unit 7

    It's also possible that the Jobs data we will be given already account for multiple occurances of a job, i.e Winged Monkeys could all be separately referenced WM1, WM2 etc.
     
  5. I agree that it should not be too complex. Production/performance seem interchangeable to me - there is no booking element, and students keep the same job type for every production, so if there are multiple performances of a production the cast will not be changing. It seems to me that the characters data requirements and crew job requirements can be held in the same table, with a NumberRequired field to indicate how many students needed for role. A Casts table with a composite key of productionID and StudentID and then a field for Job/Char ID would allow many students to have the same job/role.



    My worries are 'Each production has characters' which usually means a 1-M relationship, but it is qualified by 'only actors can be assigned to play', but I cannot see a normalised structure for an entirely separate process for crew and actor jobs. So, at the moment, I am with the 4-table solution.
     
  6. colwynexile

    colwynexile Occasional commenter

    Yes student keep the same job for every production, however the productions change on a regular basis, and so you need to have a record of who did what on each run. To me its not a case of once TinMan is cast, that person is always Timman - rather for each production run the students keep the same job (you wouldnt switch roles in a performance as this midway through the run)

    And Edexcel have in the past allowed 4 AND 5 table options in the marking scheme. To my mind its laid out thus;

    Student (1:M) Cast

    Production (1:M) Performance

    Production (also 1:M) Role (acting and back stage)

    Role (1:M) Cast

    Performance (1:M) Cast
     
  7. Having read the case study and tried this last night I think that the simpler solution is the way forward. We tried in the past to solve the problem "properly" as you would expect a database designer to do but this is where you can get stuck. I think from reading the posts and trying the solution 4 tables will work with the Cast / Roles table linking to the other three through composite keys. In this sense, like the Run Club 2 years ago, there will be one table that has thousands of records but this cannot be helped and I think that this will be the Cast / Roles with the fields discussed above. My only concern at the moment is that in the past we have been asked to create 3 forms. With the structure we have discussed Production & Jobs will not really do anything in this case study, Student will be used to add new students and cast /role to assign roles. There may be a hidden task to add a performance as with the Unit 3 exam last year. This is not a massive deal and can be easily added to the system. I will try to set up the one above and let you know how I get on
     
  8. I am going with the 4 table solution at this point also. I initially considered separating characters and jobs but this led to too many tables. Aware that Edexcel have gone with 5 table solutions in the past but seems excessive for this model.

    Clues in the scenario where 'actor' is classed as one of the jobs that students can pick so no need to have separate tables for cast and roles.

    Production and performance, I believe, are interchangeable in this scenario and expect this table to be populated with dates and times solely related to the Wizard of Oz production. This also sits well with the idea of this product as a prototype.

    The 4 tables outlined by many on here of STUDENT, PRODUCTION, JOBS, ASSIGNED JOBS seems most suitable.
     
  9. DEmsley

    DEmsley New commenter

    @robinnixon - the structure you're proposing cannot work as "number required" negates the concept of characters being unique. What links Cast to Character?

    What do you intend "job" to mean in the pupil table?

    I'm not teaching this this year so I haven't seen the actual scenario.
     
  10. stevieash64

    stevieash64 New commenter

    This 'feels' about right. I can see the student table having an actor? Y/N field, and maybe a comment box for preferences. I can also envisage the 'flying monkeys' being the main part of the test section with 9 already being present in the data set, two example records to enter the second one being the error message. I think as always we tend to over complicate until we see the data set. My gut feeling is this looks ok and I think 4 tables would do it.
     
  11. I am in agreement about 4 tables. Seems to be the most logical way of doing this. However, I am struggling to understand what form 2 is asking. It seems to be doing things in a way that, to me at least, is counter intuitive. So hoping some brainy people out there can help me out.

    1. What does suitable actor / student mean? As far as I can tell this is based on their job preference, which in turn tells us if they want to be an actor or production. Am I missing anything here?

    2. Calculating the numbers of actors needed suggests a count of the current number of records in the "assigned_roles" table. However, it also says "update records as necessary". To me, the only thing which would make sense to update is a field containing the number of spots for a job left to fill. However, that is calculated and there is no point in calculating it if we store it :/ The only thing I can think of is that we store the max number and the number currently taken. The calculation then is just a simple subtraction. This seems daft!

    Any ideas?
     
  12. It wouldn't be the first time the exam has required calculated data to be stored - I'm leaning towards number assigned being a stored field in the role table but, as usual, at this stage we can only second guess which parts of the prototype will be required.
     
  13. hamfletta
    1. I think the suitability will be gender based - ie only a girl can play Dorothy. So I have included a suitability column in my productionJobs table, then will use this on the form macro to determine if they are suitable.
    2.I agree, doing a count on the number assigned to the role, then subtracting this from the number of required for the role is the most efficient way, the comment might be there for those that are choosing to record the number of students in the role separately.It would be less efficient I think,
     
  14. rogc

    rogc New commenter

    Current thinking: 4 tables

    tblProduction: ProdID, Title etc

    tblStudent: StudentID, Name, Gender, JobType, etc

    tblJob: JobType, Description

    tblCasting: CastingID, ProdID, JobType, StudentID, RoleName

    1:M relationships from all tables to tblCasting

    Records set up in tblCasting for every role available in a production (winged monkey 1, winged monkey 2 etc), student left blank where not assigned.

    Can anyone see major problems?

    This should work registering students if there is a 1: M tblJob to tblStudent.

    Haven't worked out assigning characters in detail - RoleName could be WingedMonkey in order to select a character perhaps.

    Still confused...Is a tblCharacter table needed?
     
  15. AmosMac - I think the suitability will be gender based

    That thought crossed my mind as well. However, it says "suitable role" for production jobs. They would not be gender specific and that leads back to the same question, what would a suitable student be? That being said, I think gender for actors could be a contender. I will have an explore on my model to see what it would look like.
     
  16. The only issue with this that I have come across is that I presume that there will be some parts in the Production that have not been assigned to students and will have to be during the testing. When I have set this up with no data the relationships are fine but when you start to populate the Casting table and leave some Student ID blank it will not allow this to happen because a link field is required. I am thinking on the lines of linking the Jobs to the Students table and still including the Student ID in the Casting table but not making this a link to the Student table. On the second form this data can them just be manually added and saved. The flaws in this can then be discussed in the evaluation. Hope this makes sense and helps, or if anybody has alternatives?
     
  17. rogc

    rogc New commenter

    @neil_bolton

    How about a dummy studentID to populate unassigned castings?
     
  18. Chad78

    Chad78 New commenter

    If memory serves wasn't this approach with the train reservations scenario a few years back? I think the relationship was left with referential integrity unenforced.
     
  19. Charlie W

    Charlie W New commenter

    That's right - Deer Valley Railway scenario from 2009, but in that case the field that needed to be empty wasn't part of the composite primary key.

    I've set up a model similar to neil_bolton above, and I'm getting the same issue because the StudentID is part of the composite primary key in my "CastList" table.
     
  20. I think that I will go with 4 tables as described above and insert a primary key on all tables and link the main three to Cast with Foreign Keys. This may not be the most efficient but the exam prototypes very rarely are. At least this way I can populate the system with data and then complete the tasks with the students. It will then be up to them to work out any issues in the exam.
     

Share This Page