In my first article about an online forum, I mentioned that there might be several more advanced features to add: More formal details about the user instead of a single “name” field. You may want the user’s first name, last name and username or nickname. A nice forum would also allow users to have a profile picture, email, roles, status (to allow users to be blocked), and other information like when they last visited the forum.
Data modeling or database design is the process of producing a detailed model of a database. The start of data modeling is to grasp the business area and functionality being developed. When we work with an Agile process (in this case, Scrum), there is a tendency to assume that everyone can work with everything. However, I would like to point out flaws in that idea and my recommendations related to data modeling and Scrum.
Introduction As I mentioned in my article “OLAP for OLTP practitioners”, I am working on a project that needs to create an analytical database for on-line analytical processing (OLAP). I have mostly worked with on-line transaction processing (OLTP) with some limited reporting features. OLAP is a new area for me. In OLAP, the main focus of the database itself is simply to store data for analysis; there is limited maintenance of data.
In this final article in a four-part series, I complete the design for an online survey database to provide flexibility for multiple surveys, question re-use, multiple choice answers, ordering of questions, conditional jumps in the survey based on responses, and control over the users’ access to surveys via groups of survey owners. Introduction In the conclusion to Part 3 of this series of articles, I mentioned that I would be adding more advanced features in this article.
I am currently working on a project where we need to create a database that will be primarily used to store data for reporting and forecasting. In the past, I have mostly worked with databases used for typical CRUD (create, retrieve, update, and delete) operations of data with some limited reporting features. When performing CRUD operations, normalization is important; while in analytics, a de-normalized structure is generally preferred.
When writing a blog post on database modeling, you must be prepared that your abstract model doesn’t meet the needs of most readers. The reason is simple. Real-life database models are usually created in close relation to specific business and development requirements while the blog models are not. For the last few weeks, I have been writing blog posts about creating database models. Topics ranged from a general approach to database modeling through a simple online forum to a model for a more complex online survey.
In the conclusion to Part 2 of this series of articles, I mentioned that I would be adding more advanced features, such as: Conditional ordering of questions in a survey or, in other words, the possibility for a conditional path through the survey Administration of the survey Reports and analytics In this third article related to an online survey, I will extend the functionality to support conditional ordering of questions.
In part 1 of this article series, we discussed a basic design for an online survey. In the conclusion to that article, I mentioned part 2 would cover more advanced features for our survey such as: Different types of questions such as multiple choice questions Conditional order of questions in a survey or, in other words, the possibility for a conditional path through the survey Administration of the surveys Reports and analytics Let’s start by extending the functionality to support different types of questions.
I need to create the design for a new database which will be the data layer for an application; the application will be an online survey or polling like Survey Monkey. My challenge is that the functionality that I require is not supported by existing survey sites, so I need to build my own. What I need is a conditional survey (if the answer to question 4 is “yes,” then we ask question 5 and skip question 6; but if the answer to question 4 is “no,” then we skip question 5 and ask question 6).
Database design is the process of producing a detailed model of a database. This model contains the necessary logical (table names, column names) and physical (column datatypes, foreign keys) choices to translate the design into a data definition language (aka SQL), which can be used to create the actual physical database. When I need to create the design for a new database, in other words, the data layer for an application, I follow a few mental steps that I think can help others when they need to go through the same process.