Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

[MP6] Naive Database
Launch Autograder
GitHub Classroom

Grading

Introduction

For this MP first read the specifications then fill in the class member functions given in the starter code as specified.

Background

While we haven't formally introduced databases, I think one's interactions with spreadsheets will help make this assignment more accessible. While a spreadsheet and database are very different, a spreadsheet will provide a tangible reference to help visualize some concepts. I will do my best to This assignment is due Thursday, May 1, 2025 at 23:59 CDT. See the syllabus for our late policy. present the problem carefully to ensure it is accessible to all, regardless of one's experience withspreadsheets or databases.

To begin, navigate your browser to docs.google.com/spreadsheets and create a new sheet. You will be confronted with a two-dimensional array of data fields. The columns are typically identified upfront with a header. Each subsequent row would then contain a data record spanning the columns. Each column's row stores data of a specific type. For instance, we might have the following:

In the example above, each column specifies a type for its data: the student's "Name" is a string, "UIN" an int, and "GPA earned" a double. Accordingly, each record (i.e., row of data) is a heterogeneous data aggregate. This is shown below:

In this assignment, we will define a database as a collection of tables; a table as a collection of records of aggregated heterogeneous data. You will implement a table structure that houses dynamically allocated rows of heterogeneous, dynamically allocated data.

This assignment will require you to employ data structures and a compound type that we haven't introduced formally in the lessons. Don't worry, though! We will provide a good introduction to those structures and types in this section and again during the discussion section.

void*

You can think about void* as a special type of generic pointer, though, to understand why it's important to consider pointers in general. For our discussion, all pointers are the same size and can take on the same range of values. This makes sense since the address to an integer object should be no different than the address to a double object. What's being stored is an address, and where an integer can begin in memory should be no different from where a double might begin in memory. 

Let's say you have an int* p_int = new int(7): p_int points to a dynamically allocated integer on the free store; p_int (if evaluated) stores the address to that integer. When we dereference p_int (*p_int), we go out to that address in memory and begin interpreting the sequence of bits there according to the pointer's base type, int.

Likewise, if we had double* p_double = new double(3.14): p_double points to a dynamically allocated double on the free store; p_double (if evaluated) stores the address to that double. When we dereference p_double, we go out to the address and begin interpreting the bit sequence as a double.

With basic type casting, we could go out to any address in our program's space and begin interpreting memory from that starting point according to any time. We've concluded that the addresses are the same size, and the base type is important in interpreting a resident living at an address. If we write void* p_void = static_cast<void*>(new int(7)), we store the address to our dynamic integer object in a pointer to void. There are some implications to this: (1) we do not have a base type, so we cannot dereference p_void, and (2), the pointer is not pointing to an empty ("void") object but to a real object. However, since void* is a homogeneous type, we could create an array of void*s whose elements point to very differently typed objects:

This is exactly how we are going to use void pointers in this assignment: to "encode" an array of heterogeneously typed data in a table's row (i.e., record), and we'll maintain the proper accounting to

Activity: Void Pointers

You will store column descriptors and data types independently of the data records; however, understanding the parallel correspondence between the column vector and the row records will be imperative to interpret the data stored within a table's record.

Column descriptors and data types will be stored in the DbTable's std::vector<std::pair<std::string, DataType>> col_descs_ data member. Possible data types for the columns will be DataType::kString, DataType::kDouble, DataType::kInt. In your program, you will "decode" DataType::kString as an std::string, DataType::kDouble as a double, and DataType::kInt as an int.

While we have not detailed how you will store the row data (the next section), the underlying row data structure will be a free store array of dynamically allocated objects. The row arrays and col_descs_vector should be considered parallel arrays: each has the same size (though not necessarily capacity), and the elements are related. For example, The nth index in a row array will correspond to the nth row in col_descs_:

Given a row array, we can look up the name and type of data that each column (i.e., data field) stores.

Given the parallel nature of the row array and column's vector, col_descs_.at(0).first tells you that row[0] is the "NAME" column; col_descs_.at(0).second tells you that the type of data stored in that column is DataType::kString.

You will store the table rows in the private data member std::map<unsigned int, void**> rows_.

The key of rows_ is a unique identifier for the respective row. We will use the data member next_unique_id_ as the unique identifier when inserting a row to the table (i.e., to the map); after the insertion, you will increment next_unique_id_ by one.

A row is always allocated with a capacity of row_col_capacity_, though the number of data elements it contains is the number of columns in col_desc_ (i.e., col_descs_.size()). The idea here is similar to

Let's talk about accessing a row within a table. To access the table row with id 0, you'd write rows_.at(0). This is simple, though accessing the data is non-trivial. Since C++ arrays must be homogenous in element type, we use void pointer to store addresses to the data contained within each row column. This allows us to store addresses for DataType::kString (i.e., std::string),

DataType::kDouble (i.e., double), DataType::kInt (i.e., int). Since we cannot dereference a void pointer, we must static_cast the void pointer to the underlying data type's pointer type. This is where the correspondence to col_descs_ becomes important.

Let's say we have Reginald's record by executing void** row = rows_.at(0). To read the record's

Name field, we need to look up the data type for column 0 in col_descs_. We would observe that

The written text highlighted in green looks up the value mapped to in rows_ by the record's unique identifier (i.e., key) 0. Since this is a pointer to an array of pointers to "void" objects, we store the result in an object typed void** named row. To access the data stored in the 0th column (i.e., the Name column), I initialize a void* typed object, row_col0, with row[0]. This is the text highlighted in red. If I were to inspect the value stored in row_col0, I would see the address to the std::string object storing "Ariana". Since I cannot dereference a void pointer, I consult col_descs_ to see what type of data is pointed to by the address in column 0. I find out that column 0 stores DataType::kString (i.e., std::string) data. Therefore, I need to cast the address in column 0 to an std::string* pointer and dereference the result of that expression. In the diagram above, the complete statement is highlighted in purple. How would you access the data in the second (UIN) or third (GPA) columns of this record?

Default constructor with default behavior: the data members will be initialized using in-class initialization. For the primitive types, that's the value specified for their declaration's initializer; for user-defined types, their default constructors will determine their object's starting state.

This function's parameter is base typed std::initializer_list<std::string>. We describe what this data structure is and how you can use it in the prior text. It's important to note that col_data is a parallel "array" to col_descs_ and the array rows.

First, you need to ensure the number of items in col_data is equal to the number of columns in the table's rows. If this is not the case, throw an std::invalid_argument exception.

Second, you must create a new entry into rows_ with the next_unique_id_ mapped to a dynamically allocated array of row_col_capacity_ pointers to void objects. Don't forget to increment next_unique_id_ by 1 once you're done.

Finally, insert the dynamically allocated objects storing the col_data into the new row.

Notice that every item in the col_data list is an std::string. Therefore, if the data type for the column you're inserting is DataType::kInt or DataType::kDouble, you must convert that std::string to an int (use std::stoi) or double (use std::stod) when initializing the dynamically allocated int or

Every row's column points to a dynamically allocated object. Therefore, you must release the memory allocated to those objects. This will require you to iterate through the row, static_cast each void* pointer, and invoke the delete operator on the address returned by that cast.

Data members

Once a DBTable object is constructed, do not assign a new map object to rows_ or a new vector object to col_descs_. Instead, mutate these objects (and their stored contents) as necessary to update the

Drops an existing table from the database. This is done by looking up the table_name in the tables_ map and then deallocating the mapped DbTable. Remember that the table key is the table name and the value is the address of the dynamically allocated DbTable object. If table_name does not exist in tables_, throw an exception.

When you invoke erase on an std::map's entry, any iterators in-use for that object will become invalidated, since the std::map's underlying structure will have changed. In this assignment, we have you implement Table::DeleteColumnByIdx(), which will invoke erase on a table's unique id. This is fine.

friend std::ostream& operator<<(std::ostream& os, const DbTable& table);

nd one outside the class looking like:

These aren't duplicate declarations - the first is declaring the overloaded extraction operator as a friend of the DbTable class, while the second actually declares the method. What the friend declaration inside the class means is that while operator<< is not a member function, it can access private members of the class as if it was. This will make writing the output operator much easier, as you don't have to write a bunch of getters for all the variables you need - you can just access them directly. In summary, making a function a friend of a class allows it to access private members of the class as if it was a member function.

Friend functions in C++ are not inherently "bad," but they should be used with caution and an understanding of their implications. The key reason for this is that they can break encapsulation and hinder the object-oriented programming (OOP) principles of data hiding and abstraction. In some scenarios, friend functions can be useful, such as when implementing operator overloading. However, in modern C++, best practices encourage minimizing the use of friend functions. So, you should only use them when no better alternatives are available. We expect you to refrain from declaring your own friend functions in this course.

Constraints

Submitting your work