In This Lesson

In this lesson you will learn what Soiree needs to know about your database design.


Database designs are a model representing things that exist either physically or logically.

The party pool design represents four things

  1. Parties
  2. Menu Items
  3. Guest Lists
  4. Food Items

Soiree calls each ‘thing’ an Entity.

Entities may have relationships with other entities. The party pool’s entities are related like this

Each of these relationships are represented by a unique index in the data model

  • Relationship A (Guest to Party)

  • Relationship B (Menu item to Party)

  • Relationship C (Menu item to food item)

What Soiree needs to know

Soiree needs to know two things about each entity

  • The entity name.
  • The definition of the entity’s unique key.

For example, the party entity would be represented by this definition

Entity name: Party
Entity key: party_id

Entities are used to tell Soiree the current topic of conversation. An entity communicates two pieces of information.

  • What type of thing is being talked about: A party
    [ this is the Entity name ]
  • Which one in particular: Rochelle’s birthday
    [ this is the Entity key ]
Identification Only
An entity is used to identify something, nothing more. So, the entity definition should only specify the key values that are necessary to uniquely identify the entity.

Soiree uses this information in three ways

  1. It creates what is called an emergent data model that is comprised of all the described entities.
  2. It saves you effort when you start building the code which animates the skin.
  3. It enforces the data model relationships to help ensure data integrity.

What Soiree does not need to know

Soiree does not need to know all the other details about the database model because Soiree does not attempt to be a database modeling tool or a traditional object-relational mapping system (ORM). It simply does not need that much detailed information.
[ and you don’t have to spend the time to create or maintain it ]

Avoid Temptation
Don’t give in to the temptation to add other pieces of information to the entity definition. An entity acts like an ID card: name and number, nothing more.

Emergent Data Model

Data models are a dynamic structure that must expand or contract as the needs of the solution change. Soiree is specifically engineered to allow these changes to take place with alacrity .

Soiree uses an emergent data model. The complete data model for your solution emerges from interactions among smaller and simpler entities. Soiree allows you to define your data model incrementally and with a small set of required information. Soiree’s emergent data model then maps your tables into a cohesive object model that powers your solution.

Soiree’s emergent data model means that if you add a new entity to your model you don’t have to go back and change existing code to make it aware of the new entity. Likewise, if you remove an entity from the model you do not have to change existing code to remove awareness of the entity.

How Emergent is it?
[ would you believe me if I told you entities work together without even knowing that each other exists? ]
If this is true then expanding or contracting the model is super easy.

You will see this in action in future lessons.

Create Entity Definitions

You will now create a Soiree Entity definition for each entity in the party pool data model.

It’s a simple process

  1. Look at each table that represents an entity.
  2. Provide a name that represents the entity contained in the table.
  3. Look at the table’s unique index to define the entity’s keys.

Let’s begin with the Party table

  1. Select the com.example.party package
  2. Open a Soiree wizard for Entity
  3. Provide the entity package, name, and description then click Next

  4. Define the keys for the entity
    • Look at the unique index for the Party table.
      • tenant_id is not part of the entity key.
        Why? The tenant id is only used to identify an organization in support multi-tenancy. The tenant_id has been added to the table index simply to support organizational separation within the database.
      • party_id is the only value needed to identify a specific party within a single organization.

    • Define the key for the entity
      • Right click in the key list area and then select Add Key

      • Enter the key’s name and data type

  5. You should now have an entity key definition that looks like this

  6. Save the entity
  7. Create an entity for the FoodCatalog table named FoodItem

    The finished item should look like this

  8. Create an entity for the Menu table
    All menu items are associated with a party. Stated another way, each menu is a child of, or belongs to, a parent named party.

    • Create the MenuItem entity

    • Define the keys for the entity
      • We can specify the relationship with the party entity as shown here

      • Add the food_id value which is part of the menu item’s unique key.

      • You should now have an item that looks like this

  9. Create an entity for the Guest table named Guest

    The finished item should look like this

You should now have 4 entities defined as shown here

These entities will be used in a future lesson when you begin writing the code needed to animate the skin.

You are finished with this lesson.