Nutrition Database Design

Overview

One of the main difficulty of this project is to set up an easy to use nutrition database application, or a sub-API to facilitate all other operations.Nutrition database serves as the foundation for the entire API. There are two sets of challenges at this point (June 17, 2017) regarding the nutrition database:

• Completeness: Completeness of the database manifests at two levels.

  • First, for a single ingredient is the information complete enough? Are all nutrients there? How are they measured? Who measured them and can they be trusted? A trustworthy data entry is the key for credible presentation of nutrition information to customers and key for future scaling.

  • Second, no nutrition database covers all products, but at the level of the entire database, what are the missing data? Are they needed right now? If new data is required, can there be a credible way to obtain its nutritional values?

• Additionally, think about how the data should be requested. Should it be directly from mongodb?(Probably not, as you do not want so many people connected to the database server) So using HTTP requests is probably a better idea. Think about how EDAMAM, nutritionix and USDA are doing, maybe REST access could be a better solution.

• Communicability: Given a large database of nutrition information about foods, the relative ease of retrieving information of relative importance to users is the bottleneck for the value of the database. If users' need cannot be fulfilled, the database is good as none. Note here, the word relative is used to emphasize the scope of functions required, and it varies according to different users:

  • Application User: Those are the users directly facing the graphical user interface, having specific tasks in mind and can only use the functions provided. They have no way to access the source code and see the hidden functionalities required and no interest in exploring the possibilities. They probably do not understand the information returned so a more abstract and high-level interpretation is also required. All they need to ease to use and great instant value. Those users include our customers, software users, design chefs.
  • Professional User: Those are the users who need to perform more advanced searching and need to apply varies filters to find their intended items. They have a clear target and they can understand what the information means. They have a different goal in mind from the application users, a professional one. Those users include nutritionists, doctors, meal designers (not chefs).
  • API User: Those are novice to relatively experienced users. They want to explore the full potential of the database, but they are not familiar with the database language, or they are contained by the API from the root database. For them, additional functionalities are provided through arguments in methods. Those users include developers wanting to build new applications based on this API, and power users who wish to achieve their goal through command line or their own script.
  • Database Maintenance User : Those users may not be able to programme. However, they are the people who keep the database updated, add new information when required, remove outdated information. They should be able to perform regular checks on the database information and communicate with nutritionist or database design about the condition of the database.

Data Structure

The data structure of the nutrition database is described in the data structure section, but I will anyway place it here for ease of reading.

{
    name : { 
             sci : str,
             common : list,
             long : str,
             zh : str
           },
    portions : [
                 {
                   g : float,
                   amt : float,
                   unit : str,
                 },
                 ...
               ],
    nutrients : [
                 {
                   code : int,
                   name : str,
                   value : float,
                   abbr : str,
                   units : str,
                   meta : {
                            maxval :  NA,
                            lower_error : NA,
                            rounded : NA,
                            derivation : NA,
                            minval : NA,
                            mod_year : str,
                            data_points : int,
                            is_add : bool,
                            degrees_of_freedome : NA,
                            sources : list,
                            source_type : str,
                            upper_error : NA,
                            imputed : NA,
                            conf : NA,
                            studies : NA,
                            mod_month : NA,
                            stat_comments : NA,
                            std_error : float,
                          },
                     ...
                ]
    meta: {
            ref_per : str,
            ref_desc : str,
            fat_factor : float,
            carb_factor : float,
            protein_factor : float,
            nitrogen_factor : float,
            ndb_no : str,
            fndds_survey : NA,
            footnotes : list,
            langual : list,
          }
    group : str,
    manufacturer: str,
}

Proposed Functionalities

Now the challenges are stated, it is now crucial to state the intended functionalities to be provided for the three types of users. The key idea behind the priority level of users is that Functionalities provided for higher-level users is a superset of that for lower-level users, but lower-level != simple.

Application User

Function	Description	Method
Select a single ingredient by name	Input a name, select from list	.find({"name": value}), .find({"_id" : value)}
Select a single ingredient with filters (user-concerning, such as category, nutrition type, season, etc., but not name	Choose options for filters, select from list	Document Query with filters & operators

Those two functions should form the basis for all functionalities concerning database for application users. All other functionalities would be based around this due to users' lack of knowledge about other information.

Professional User

Function	Description	Method
Select a single ingredient by name	Input a name, select from list	.find({"name": value}), .find({"_id" : value)}
Select a single ingredient with filters (user-concerning, such as category, nutrition type, season, etc., but not name	Choose options for given filter values, select from list	Document Query with filters & operators
Select a single ingredient with greater control (professional knowledge, such as nutrition information, professional purposes	Choose filters, options for discrete values, sliders for continuous values	Document Query with filters & operators
To be continued ...

Exploratory search is the key feature for professional users at the database level. Professional data presentation is key to make sure the exploration can be convenient, fast, thorough.

API User

Function	Description	Method
Select a single ingredient by name, filters, or range data	options offered as arguments, individual args or organize together as a search condition object, should return as an ingredient object	Document Query with filters & operators
Operations required to perform on ingredient objects, such as compare, addition etc, reports, looking for pairs or possible recipes (Needs expansion)	Exist as object methods	Operation on the object, case by case
To be continued ...

Note on terms above:

• Selector Object: Attributes of the class serves to feed into the Query. Raw object exerts no constrain on query, equivalent to db.col.find(), further functionalities such as natural language query can be scaled here by transforming natural language description into attributes of the selector object.
• Operable object: This is returned as an ingredient class. Further operations on the ingredient or ingredients, such as altering amts, addition, subtraction, forming recipes, comparison, can all be done through this object. Additional info such as the ingredient type in nature (seasoning, main) can also be incorporated in some way.

For API users, refer to the book Practical API Design. In some way, API users can use the available tools here to produce all the functions needed for the above two types of users. In fact, when combined with other APIs, this API (ragdoll) should be able to produce more powerful applications. This is corresponding to the key idea from the book Practical API Design, by providing cluelessness to the users, they can quickly make use of it and bulldoze it with other APIs to form a greater solution. Think about back-compatibility and how users could use the API.

Database Maintenance User

Function	Description	Method
Add new ingredient information into the database	Through predefined form, enter data, validate and submit	.insert()
Remove outdated ingredient information from the database	Careful validation for removal required, permission is important. Reason for removal should be stored somewhere for sometime, and must be reviewed before total oblivion.	MongoDB remove
Modify ingredient information in database	Through predefined form, change data, validate and submit	Careful validation for removal required, permission is important. Reason for removal should be stored somewhere for sometime, and must be reviewed before total oblivion.
Evaluation of ingredient information	Generate some sort of report for evaluation	If you see this, think!
To be continued ...

This group of user is special, as they are the only ones actually changing the database. Therefore permission is strictly required, and defensive measures against wrongdoings must be properly designed.

More thinking is still required, and expansion on the functionalities is required. After that, review API design principles and think about how to structure.