The MySQL Documentation refers to the SUM() function as an aggregate or group function. In light of this, I would call it an aggregated column since the MySQL Documentation starts with:
This section describes group (aggregate) functions that operate on sets of values. Unless otherwise stated, group functions ignore NULL values.
As for the CASE statement, the book
page 82 paragraph 1 and pages 88-92 refers to CASE as a conditional control statement. Personally, I would call it a conditional control column or, simply, a conditional column.
Relational database theory does not include the use of the word Field. Dr. E.F. Codd, who wrote the series of papers that provide the theoretical basis for RDBMS's never used the term. You can read his seminal 1970 paper A Relational Model of Data for Large Shared Data Banks if you want to check.
Terms like Domain, Table, Attribute, Key and Tuple are used. One reason for this, is that his papers were largely concerned with relational algebra, and the way a particular implementation would define a table in a database wasn't considered by Codd to be important. Vendors would flesh that out later. People also have to understand that historically, RDBMS's evolved from existing hierarchical and network databases that predate them, AND the inner workings of an RDMBS still have to be concerned with data organization and storage.
In common use, and you can easily verify this by simply doing a bit of googling, Fields and columns are the same thing.
PC Databases like DBase, Access and Filemaker typically use "field" instead of "column". "Attribute" is another term that can be used interchangeably.
For example, here's a link to the MS Access manual on adding a "field" to a table. It's clear to see that in MS Access a "field" is equivalent to a "column".
The same holds for Dbase and Filemaker Pro.
Sometimes people will refer to a specific value in a specific row as being a "field" or more properly a "field value" but that does not make the use of "field" when referring to a column or column-equivalent-concept incorrect. This does tend to cause a level of confusion because people have used "field" to mean different things for many years. In relational theory -- a single atomic value is referred to as a "Datum".
If someone stated that a "field" is one value in a relational database and not the same as a column, that is their opinion, since "field" is not part of relational database vernacular. They are neither right nor wrong, however, throughout the database world, field is more often used to mean column.
With that said, projects and teams often have to work out an understanding of how they want to use particular terminology within the project to avoid confusion.
You aren't wrong, but you also might decide to simply go along with the convention being used, or avoid using the word field altogether in favor of "column". With relational databases, "Table" and "Column" are the building blocks that exist in DDL and it's best to just use those terms and avoid "field" which isn't used, nor clearly defined.
Best Answer
Splitting given names from surnames is not normalisation. What would be normalisation would be if you created a series of tables that contained additional details about some of the columns in your table.
For example, you could create a
HOUSEtable that contains information about the house other than the name, such as it's catch phrase or home town etc. You might do something similar withTITLEandBOOK.Don't worry about nulls in your case. Some people are concerned about too many nulls because it can be a sign that your design is not correct or because they are worried about wasting disk space. In your case neither of these concerns is germane.