Continued from:
Architecting Sharedove Conference Organization Solution: Data First (Part 1)
The Sharedove Conference Organization solution is intended to help the conference organizers to store and manage information about conference sessions and participants, as well as to support all business processes which are taking place during the conference.
Having the "Data First" approach in mind, I will start with the Conference Organization Solution Architecture with the conceptual and logical schema of the solution’s data model.
Data Model: Conceptual Schema
Even if it called a schema, I prefer creating first version of the conceptual schema in a descriptive way. This way we can define each entity, and its role in the whole model, with few sentences. That helps us, and everyone else concerned, to easily recognize purpose of each entity, and to understand the relations between them.
One of the standard master data entities, which will also be used in the Conference Organization Solution, are Countries – we will need a standardized list of countries, defined by the ISO 3166 standard, which will be referenced by various other entities in our data model.
Further, we will need to define the session Tracks. Each conference is consisted from one or more tracks – in the IT conferences, those are usually Development Track, IT Pro Track, Information Worker Track etc. They are used to "group" the sessions by the common topic or product, and they are usually parallel – all of the sessions in one track are presented sequentially, one after another, but they are parallel with the sessions in another tracks – they start and finish at the same time with the sessions in another tracks, thus giving the visitors possibility to participate in the sessions from various tracks.
All of the sessions are presented in the Rooms. In practice, all of the sessions in one track are presented in one room, so that the visitors who are interested in one specific topic or product do not need to leave the room. We will need to know the address of each room (does not need to be a formal address – sometime one descriptive line of text is enough), as well as the maximal number of participants, which will be later used in the process of registering the visitors on the session.
Entity Sessions will define data for each session in the conference – title and description of the session, speakers, to which track session belongs, and in which room and at what time it is being held.
Each session can have one or more speakers. Since speakers are noting else than one kind of participants at the conference, sessions entity will have a one to many relationship to the participants. Participant entity contains all the necessary data about a conference participant – from the personal and bank account data, to the status relevant data, for example, is participant a speaker, visitor, sponsor or journalist, and is he paying for the participation, is he being paid, or none of both.
Since all of the conferences in the world are organized upon some topic, there is usually a certain profile of the people who is coming to those conferences. For example, in the case of the IT conferences, you can expect to have developers, IT Pros, business analysts, project managers, and similar. The organizers will want, on the end of the day, to know who was coming to their conference, so there is a need to isolate Professions in the separate entity, which will be referenced from "Participants" entity.
Most of the participants in the conference will be coming from various companies, and the organizers will in any case want to know from which companies the visitors and speakers are coming.
These companies can also be in various sponsoring statuses, ranging from platinum sponsors to the exhibitioners. Conference organizers might give special benefits to the employees of the companies which are in the sponsoring status, like discounts or free entrance to the conference. Thus, it is necessary to identify and isolate sponsoring statues, so that they can be further tracked.
Conference participants will, of course, participate at the sessions as visitors. Organizers will want to track the session participation, and this data is usually gathered on the door of the room where the session is held, so that organizers can know how many visitors are taking part at each session, and maybe to close the door if the number of the session visitors is getting larger than a number of the chairs in the room, where session is taking place.
Each visitor who participated at a session, will be able to rate the session by answering a number of questions about the session and the speakers, either with the 5-stars rating system, and/or with the descriptive answers. Questions are common for all sessions, they can be speaker or session specific, can carry more weight in the overall rating calculation than the other questions, and can be answered with the numeric (5-stars system) and/or descriptive answers.
This is how the relationships between our entities look like (Conceptual Schema Diagram):
Image may be NSFW.
Clik here to view.
Data Model: Logical Schema
After the conceptual schema has been created and agreed upon with all interested parties (usually business owners and business users), the next step is creating of the Logical Schema of the data model. This is where we define all entities with all columns in detail, as well as all the other relevant information about the data we will be manipulating. Please note: the logical schema will be a foundation for creating business entities in the solution, and as such, logical schema needs only to follow our business requirements and use cases, without considering our actual data layer implementation.
We will define and describing the following properties for each entity column:
- Column name – name of the entity column
- Column type – use type names as they are called in .NET, and include all specific information if needed (for example, number of characters in the char type if it has been fixed, or the number of decimal values in the decimal type)
- Description – free text description of the column, which explains what is expected to be stored in the field values
- Required – Does the record require this value to be filled in, or can the column value be null?
- Indexed – Will this be a indexed column in the future, a column that we will base our queries upon? State if the index is unique and/or primary key
- Relation – is the value stored in this field contains a value which is of another business entity’s type, or a list of those, that should be stated as well
- Validation Rules – state validation rules for the values stored in fields of this column, if any
- Localization – do the values stored in fields of this column need to be localized – stored and presented in multiple languages?
- Comment – any additional comment about the column
Logical schema of the Sharedove Conference Organization Solution’s data model does not necessary needs to be identical with conceptual schema, but it needs to follow its spirit. This means, we can, and we will, reorganize some entities described in the conceptual schema, to achieve easier data management, but we should not add new relevant entities, delete the existing ones, or change some of them in a way that it changes the business logic connected with the entity.
For example, I will be splitting the "Participant" entity, described in the Conceptual Schema, on two entities. One will be called "Person", which will contain person-relevant fields, like name, title and address. The second will remain under the name "Participant", and it will be inheriting the "Person" entity, adding columns which are relevant for the person visiting the conference (like status of the person on the conference). This will help us, if there is ever a need to expand the data model and add other person-specific entities, to use the existing "Person" entity, without duplicating all of the person-relevant fields.
Furthermore, both "Person" and "Company" entities will be containing few identical fields in which address and bank account info will be stored. Thus, we will create two new entities – "Address" and "Bank account", and reference those entities from Person and Company entities, so that we don’t have redundant columns in those two entities.
Logical Schema for Conference Organization Solution
So, this is our logical schema, which will be used in the Conference Organization Solution:
Image may be NSFW.
Clik here to view.
(click on the image for the PDF document)
Creating Business Entities from Data Model
After the logical data schema has been defined, we need to do something with that. If you look at the simplified architecture model from the "SharePoint Architecture – What are we talking about here?" article, this means that we actually start with the Business Entities part of that model.
Image may be NSFW.
Clik here to view.
We will create business entities only with the business needs and use cases in mind, and that means, they will follow 1:1 our logical data schema. We are modeling the objects according to logical schema, and we don’t care much at this point how that data will that be represented and implemented in the data storage. Implementations will anyway vary between different storage options – for example, in SharePoint, we would use a multiple choice lookup field to assign speakers to the session entity, and in SQL Server we would create this "one to many" relationship by creating a separate table which holds session and speaker primary keys. But this is something which we will later take care of, for now, our business entities only need to follow our business needs. In the software architecture, this is called Domain Driven Design, where we model our business entities according our business needs, and not according to existing data structures.
Image may be NSFW.
Clik here to view.
Business Entities are already checked in, in the CodePlex project which accompanies this series of articles about SharePoint Architecture, so feel free to take a look at it.
Continue to:
Architecting Sharedove Conference Organization Solution: Data First (Part 3)