Question

Please help with this SQL problem. Thank you.

a) A fast-food restaurant has order tickets with numbers that are sequentially assigned, with numbers like the ones below, which were somehow chosen from several months’ worth of daily sales. (Perhaps by searching for meals eaten by Joe Blow.) The restaurant has a funny little computer system that has 100 memory locations for hash destinations. The software uses a simple “modulo 100” hashing formula. Which ticket numbers below, if any, will create collisions In the hashed-to (“destination”) memory locations?

53207     53001    28125    9999    33308    53208   42325   23230    23231

Justify or explain your answer:

b) Suppose that now the search is expanded to include anybody who ordered French fries, and there are more than 60,000 such ticket numbers that are supposed to be hashed into the 100 memory locations. What will happen to the hashed search?       Why?

c) Name or describe at least one method for dealing with (but not preventing) hash-table collisions when they do occur. Assume the hashing algorithm (formula) and the size of the hash table will not be changed.

d) Suppose that instead of having sequential ticket numbers as the input to a hash function, you want to hash or index by postal Zip codes like 33431 and 33432. Suppose most of the restaurant’s customers are from the Boca Raton area.   What problem would arise if you use the simple mod-100 formula of part (a) to do the hashing?    Explain your answer.

Answer 1

A) The software uses a simple “modulo 100” hashing formula.

Ticket Number Hash value

53207 07

53001 01

28125 25 **

9999 99

33308 08 *

53208 08 *

42325 25 **

23230 30

23231 31

Collision :

As u can see, for ticket number 28125 and 42325 the same hash value is generated= 25

Similarly, for ticket number 33308 and 53208 we get the same hash value= 08

b)

if there are more than 60,000 such ticket numbers that are supposed to be hashed into the 100

as 100 locations are not sufficient to store the 60000 tickets , we may have to delete the tickets after new ticket with hash value is appeared.

else we have to increment the size of hash table (rehash) ,

C)

another solutions like quadratic probing , Chaining, techniques can be used

Quadratic Probing

Here SIZE=100

hash(x) = x%100

If  hash(x)  is already occupied , then we try position [ hash(x) + 1 ]% SIZE
If [hash(x) + 1] % SIZE is also full, then we go for (hash(x) + 2) % SIZE and so on...

 in our example

28125 and 42325 the same hash value is generated= 25 so we put ticket 28125 to position 25 and ticket 42325 to position 26

ticket number 33308 is placed at position=08 and 53208 we put in position 09

Separate Chaining

Chaining allows many tickets to exist at the same location in the hash table. one example can be -->

10 None None None None None 26 93 17 31 54 20

d)

instead of having sequential ticket numbers as the input to a hash function, you want to hash or index by postal Zip codes

As zip codes are input to hash function , it will store the orders as per zip code

But , problem occurs if u have many customers from same zip code

e.g-> if there are 50 customers from zip code=33431 then for every order the hash value will be=31 hence you have to store multiple orders in same hash value position . hence leads to the collisions

If we go for chaining then it will increase the search time.