You are creating a DBMS capable of handling a terabyte table. This introduces a few challenges. For starters, you want this to run on the FAT-32 (old windows) file system, which has a 4GB file size limit. This means that a single table may have multiple files. Assume 4KB blocks. For an index, this means that your block pointer needs to include both the file name, and the block within the file. For purposes of this question, assume that Kilo/Giga/Tera refer to powers of 2 (1024/2²⁰/2³⁰), rather than the decimal values.

3. Data sizes

a. How many blocks can we store in our (terabyte) database? Don't worry about file system overhead, assume you can use the entire terabyte for files containing the disk blocks.

b. Within an index, or within a data block in a sequential access method file, we need to store pointers to the block containing the indexed record. How big does this pointer need to be (in bytes)? Assume that file names can only contain 26 lowercase letters and 10 digits, and they are stored as a fixed-length character string (one byte per character), the record pointer within the file is stored as an unsigned integer, and that we don't do bit-packing (i.e., we don't use the same byte to store part of the file name and part of the record ID). You'll need to calculate things like how long file names need to be.

c. Assume that each person's record is 100 bytes. How many people can be stored in each block? Note that there may be some additional things beyond the records you need to store in each block. You'll want to explain your answer.

d. Given that each person's record is 100 bytes, what is the upper limit on the number of people we can store in our (terabyte) database? Assume that the 10 numeric digit ID is a primary key.

e. Repeat this above questions, assuming that person records are variable length, with an average of 500 bytes and a maximum of 3Kbytes. Note that some answers may be unchanged.