Lesson video

Hello, my name is Mr. Davidson.

I'm so pleased that you've decided to complete your learning with me today.

We are going to do brilliantly.

Today's lesson is called "Making a Dinosaur Identifier" from the unit "Organising Data Using Databases." We are going to work really hard together today, but I'm here to help and we can learn together.

By the end of today's lesson, you're going to be able to independently create an identification tool.

There are two important keywords that you're going to see throughout the lesson today.

The first is identification, and that's the process of identifying something.

We also have the keyword real world, and that's something that happens in real life.

Look out for those throughout the rest of the lesson.

We have two learning cycles today.

The first is creating a branching database following a plan.

Whenever we create something that we've planned, it's a good idea to test what we've got and you're going to test branching tree diagrams. That's going to be before you create the actual branching database based on the diagram.

It's almost like a trial run before you make what you need to on the computer.

It's very important to check that your branching tree diagram works well.

You're going to check your branching tree diagram is structured how you want it to be and that it helps with the identification of your dinosaurs.

Remember a few things about your diagram.

It needs not to ask too many questions, and it should always ask yes or no questions because of the attributes of what we're looking for.

If you need to, once you test, you should make changes, and you should do that now before you get on the computer and actually create your branching database from your diagram.

Doing it this way makes sure you save yourself a lot of time and effort later on.

You've got a choice for this lesson.

It may be you've got an existing diagram that you can use from before.

If you don't, I provided one in the additional materials for this lesson and you're free to use that.

So in testing our database, you can work with a partner, pick a dinosaur that appears on your branching tree diagram, but don't tell your partner which one you've chosen.

Get your partner to ask you questions based on your branching tree diagram.

Answer the questions based on the information on the fact card for the dinosaur that you've chosen.

And then once your partner has been through all the questions, they should be able to tell you which dinosaur you picked.

If they picked the same one that you were thinking of, that's great.

Your diagram worked exactly as intended.

Be prepared though that it might not work out that way, in which case try and spot at which point things went wrong.

Once you've done that, I want you to swap roles and try again with the other person's diagram.

Now, it may be you don't have anyone to work with, and that's absolutely fine as well.

You can do this all by yourself by randomly picking a card and asking questions to yourself.

The only thing to remember is to be honest.

Don't assume that the answer to the question is the one that you want.

Try and be objective about the answers that you are giving.

So before we get onto that, let's just check you've understood.

I want you to think about using a branching tree diagram to plan your branching database.

I've given you some keywords there, and I want you to complete the sentence.

So when we're using a branching tree diagram to plan your branching database, we've got to consider that before you create your branching database, it's important to check that your branching tree diagram works well, and let's just think in a bit more detail about this.

I've given you here part of a branching tree diagram.

Do you think it's true that this dinosaur can be identified with this part of a branching tree diagram? Yes, it's false.

The dinosaur can't be identified with this part of the branching tree diagram.

Did you spot why? Well, we've got a big long series of questions at this part of the diagram.

However, I've only shown you one half of it.

Starting with the question, is it brown? I've only given you the yes branch.

This dinosaur here is purple, so none of the subsequent questions will actually apply to it because we won't be in this part of the diagram.

Always check and work through and think about objectively what the answer should be and if it's doing the right thing that you need it to do.

So before we get onto the task, make sure you've checked with someone else or yourself that your branching tree diagram works exactly as you want it to.

Okay, having tested it and happy that it works, I want you to go to that link there.

Once you're in the website, I want you to use your plan to make your branching database from the plan that you've just checked.

Pause the video and take care in reading your plan exactly as it is and making the database that corresponds with that diagram.

When you come back, I'll show you an example of someone who's done something similar.

Well done, there was a lot of practical work and you probably made lots of changes.

If we look at Aisha's plan, we can see here that she's got her dinosaurs and she's been able to group them individually by asking the right questions at the right time.

The first question she asked was, is it brown? That allowed her to have two groups of four, a group of four where they were brown and a group of four that were any other colour other than brown.

For the group that were brown, she asked, is it a herbivore? Because there were two herbivores and two carnivores, again, that would allow that equal split that makes such a good diagram.

For the herbivores, she asked, is it longer than nine metres to get individual items in each group? And for the non-herbivores, she asked, does it have wings, because only one of the two did.

On the non-brown dinosaur section, she asked, is it a carnivore, because two of the four were, and for the carnivore, she asked, does it live in the sea, which one did and the other didn't.

For the non-carnivores, one was blue and she put that in the yes group.

The other was grey, so it wasn't blue, so it could stand on its own.

Having tested all that, she used that same plan to create the questions in the branching database.

She started with her set of data, which was the dinosaurs, and then you can see that those questions match with her plan.

And successfully, she has managed to get each of the dinosaurs into their own group, and the maximum amount of questions that we have to ask are three.

Perhaps if we choose the blue dinosaur just to check, she asked, is it brown? So she followed the thumb that was pointing down because the blue dinosaur is not brown.

She then asked, is it a carnivore? The blue dinosaur is not a carnivore, so it follows the no path.

But the last question asks, is it blue? In which case, the positive answer leads us to our final group.

Well done.

We've created a branching database from our diagram that we created as a plan.

We're going to consider in the second part of the lesson how branching databases are used in the real world.

We've seen examples in this lesson that we can use branching databases for identification of animals.

If I take this ladybird here, we could ask questions like, does it have antennae? Does it have wings? Does it have spots? They're all good questions that are yes and no answers.

They are also attributes that apply to the object that we're looking at and could equally be applied in any question, in any structure for our branching database.

So if we answer yes to those questions, does it have antennae? Yes, it does.

Does it have wings? Yes, it does.

Does it have spots? We can see that it does.

If we answer all of those questions in order, we can confirm that we have a ladybird.

Now, I want you to think of any other similar examples where we ask questions in order to categorise what we're looking for and confirm it's what we are trying to find.

Have a think.

What else could you use a branching database for? One example you might see in computing lessons quite a lot, fault finding.

Now, it may be that the computer's not working.

You arrive in the computer room and you try and use the computer.

It's usually got a screen where you can put your username and password in, but it's just a blank screen.

If you were trying to fix that, or probably you should let your teacher fix that, is the power lead connected should be the first thing that you check.

Notice how I've asked that as a yes/no question.

Either the power lead is connected or it isn't, but we know that that will result in the first fix for the fault and trying to find it.

It may be then that the power lead is connected, so you might check something else.

The next sensible suggestion would be, is the screen working? Maybe the cable has come out that connects it to the computer, or maybe it's just broken and something's gone wrong inside the monitor itself.

If you feel that the screen is working, but it does have power, then you should probably check for any damage.

Now that might result in two different actions.

We may find it is damaged, in which case it needs to be replaced, or there might not be any obvious signs of damage, which would indicate a further problem.

What we've got there is an example of an ordered set of questions to get to a result that we need to find.

There can be lots of different possible answers, which would give us different solutions to the problem.

That is a perfect example of a branching database.

Let's consider another one.

It may be you're not feeling very well and you go to the doctor.

The doctor is likely to ask you lots of different questions in order.

First question should be, do you feel warm? If you're not feeling well and you feel warm, that might give the doctor some clues to the types of things that give illness based on you feeling warm.

Being warm is a symptom of being ill in certain ways.

However, it's not the symptom of everything.

Once the doctors ask that, they might ask you, do you have a headache? Notice how these questions are ordered.

Symptoms such as feeling warm or not feeling warm when you're ill probably give a range of different illnesses that you could have and a range of illnesses that it can't be.

What the doctor's trying to do is eliminate what is not wrong with you so they can find what is wrong with you, and a headache would follow on from feeling warm.

They may also ask you, are you tired? What the doctor is doing is a bit like fixing a computer.

They're trying to figure out what exactly is wrong with you so that they can find out what it is that is causing your health problem.

So let's think about that.

Is this statement true or false? Branching databases can only be used to identify objects.

What do you think? Yes, I agree.

The answer is false, but why? Well, branching databases have many real world uses, such as finding faults or diagnosing illnesses.

It's not just about being able to look at an object and saying what it is.

If we ask the right questions in the right order, we can use branching databases for many different applications.

Let's try another.

Let's think, is this statement true or false? You could use a branching database to solve a problem.

For example, if your phone isn't working.

What do you think? Yes, it's true, but why? Well, branching databases can be helpful in many troubleshooting situations by asking questions to help diagnose the problem.

For example, is your phone charged? Have you got the latest software installed? It's important with the questions though, as we've seen before, that they are yes or no because we don't want questions that lead to multiple different answers.

You're gonna have a go at that on a task yourself now.

I want you to think about where else you think branching databases be useful in the real world.

Think about perhaps fixing a car or perhaps an AI tool that might ask you and respond to questions, or perhaps your local vet.

What I want you to do is suggest real world applications for branching databases and explain how it might be useful.

Pause the video and have a go now.

Think carefully about what you're doing and think about the detail and being able to explain to someone else why you think branching databases are useful in that particular case that you've chosen.

Well done.

You did really well there.

Jacob's gonna give us an example that he thought of in a situation of why branching databases could be useful.

Jacob says that he thinks a branching database could be helpful to someone who runs a car breakdown service.

They could use it to troubleshoot problems that the customers have by asking key questions.

Some questions might be, does the engine start? Are there any warning lights showing? Is it making any unusual noises? This structure might help cut down the time needed to diagnose a problem.

Importantly, if they ask questions that create equal groups, we can ensure that we ask the minimum amount of questions to get to the root cause of our problem.

You can see how planning a branching tree diagram and then a database based on that can help us troubleshoot and problem solve later on.

Let's just recap what we've done.

Firstly, we considered that you can create your own identification tool using a branching database software.

Branching databases can be created based on a plan to ensure that the questions work correctly to split the objects.

Very important to plan carefully and test our plans before making them so that we don't have to redo our work later when we find that our database doesn't do exactly what we need to do.

Lastly, we also saw that branching databases are used in real world situations to solve problems or identify health conditions.

There are many, many different ways we can use branching databases in the world around us, not just the ones that we've seen today.

Try and have a look for where that happens in the real world and consider that maybe someone has designed a branching database that you use outside of school.