SmooreCore: Techie Research: Physical Model

During the process of looking over the logical model, I was able to implement a physical model by hard work and determination. Utilizing each piece of information used within the logical model and how it is organized allowed me to build a physical model easily. The physical model shows everything from the first name for each family member to their gender and if they are going to drink any alcohol. During the process of building the physical model I did decide to remove a few unnecessary fields that I original thought would work from the logical to the physical model.

Within the logical model each entity contained attributes, such as family member being the entity and first name an attribute. This made it decently easy to put together when building the physical model using the logical model as an example. Each column is a field from within the logical models entities. Logically speaking of course, when planning and organizing a family reunion there are only a few things to keep in mind when designing a physical model for a database, family, location, and relaxation. With those key concerns in mind I was able to identify my main three tables to implementing a physical model, family member, reunion, and cabin. Each containing important information for planning and organizing the family reunion smoothly.

Depending on the characters being used within the attributes helped me determine what each datatype would be. For example, first name used a datatype of short text as it can hold up to 255 characters; I used the same datatype for the last name also. When it comes to the phone number column I chose the short text datatype here, even though a majority of people would believe this should be a number datatype. Each portion of the phone number is separated by dashes and therefore requires the ability to enter something other than a number, which in turn requires a short text datatype. The address field used the long text data type, even though there are numerical values being used there are also alphabetical characters which this in turn requires a long text datatype.

For the gender column I chose the short text data type as it would not exceed 255 characters. When a family member responds stating they are attending the column for attending uses the datatype yes/no, so it is a simple entry when filling out the form. When the family member decides to bring guests there is a column using the number datatype to enter the number of guests attending? Following the guests is the total attending datatype which is also using a number. Then it comes down to the food they choose to eat while attending the reunion, which is a long text datatype. Afterwards, is a beverage column to choose which beverage they will drink while attending, which is a long text datatype also. Last but definitely not least is the alcohol column, which is a yes/no datatype in case they plan to drink alcoholic beverages while attending the family reunion.

Overall, after much consideration I have come to a conclusion the below snapshots of my physical model is a great start. Although I am sure at some point I will make changes to it whether it be drastic or simplistic, this is definitely not the last of the modifications. I cannot wait to move forward into implementing this database and possibly using it as a template for future family reunions.