Before we start creating the geodatabase, we need to design a template that includes the tables, fields, and data types for the Bestaurants project. This template is called the geodatabase schema.

So, let's design the logical schema for the Bestaurants project. We will start with a very simple design where we create the basic atom dataset in the geodatabase, the feature class.

According to the case study, we need to create a geodatabase that accommodates diners, cafes, restaurants, bars, and lounges. So, we can create each one of them in a separate feature class, and then we need to give appropriate fields for each feature class. Take a few moments to answer these questions: what feature classes will you include in the geodatabase? What attributes will you use for each class? What are the data types for these attributes? Take a look at the following table:

There are a lot of ways to design the schema for a geodatabase. There are really good ways that keep your geodatabase healthy in the long run, and there are bad ways that are inefficient. This design is a simple one; it is not the ultimate, and you might come up with a better design. The only reason I selected this is for its simplicity, and there is definitely plenty of room for improvement. You will learn how to create an efficient schema design in Chapter 3, Modeling Geodatabases, as you are introduced to more geodatabase datasets.

As you can see, we have merged the bars and lounges into one single feature class. We have used point geometry to represent these feature classes since it is easier to sketch, which could be identified with a Global Positioning System (GPS) device. These feature classes are also fast to draw, and we don't really care about the boundaries. However, it all depends on your requirements; whether it is necessary to identify the boundary of a certain feature or not. You may use polygon geometry if you want to.