The surprising skill that keeps me relevant
I want to share my personal story in this post. Something has come up and made me ask myself — what is the skill I learned that I feel thankful for until today? In hindsight, it was quite a silly story when I thought about it. I had no idea that this skill would have helped me stay relevant, considering that I was not fully aware of what I was learning.
It is a database skill.
About 25 years ago, I started my new job in a small financial company. My supervisor at the time told me after the first week of training that he was disappointed with my computer skill. He said as I graduated from this university, he expected that my computer skill should be better than this. I took it as an insult, and I don’t react well with any insult. I decided to enrol in a Master Degree in Information System Management. On the first day, a lecturer asked the class if we had experience in something called database programming or management. Everyone except myself raised their hands. I thought I picked the wrong course.
I got my first assignment a month later to build a database application using Microsoft Access database. I somehow could do the project with lots of reading and researching. In the following semester, I enrolled in a database management course. And that when my small dots connected. I continued with another Master Degree in Information Technology Management. I still had no idea at the time the implication of my database knowledge in a business context. Until I got my first job when I moved to Australia, I was so thankful that I had an interest in the database area.
To be clear, I am not a programmer. I wish I could do programming. I only have a basic understanding of database.
Why is the database knowledge so useful?
You would be surprised how bad the data capturing, data management, and data structure of many companies are. Many businesses don’t have clear visibility of their businesses. From my experience, this issue comes down to two major factors:
- Data structure: many companies don’t have a good discipline to collect and manage data. Their data are kept in different formats, structures, and many are incomplete.
- Data analysis: to analyse data, you need to have datasets that are ready to be analysed. It sounds like a no-brainer. However, if a business suffers from ill data management in point 1, it has to spend 70% or 80% of the time to prepare data to be in the format that could be analysed.
The database management knowledge, even at a very basic level, would help you (an employee) to alleviate the above two points. You would know the data structure concept and how to store data in what format. The data structure skill alone could help you to notice something in a dataset. I often spent a lot of times preparing data for other departments such as Finance and Customer Experience. During the preparation process, I always notice trends or themes from a dataset. It is the first step for knowledge and insight development.
Basic database principle
You don’t have to be a programmer to understand the database. In this section, I will share what I know that help keeps me going in my career (or at least it helps me to have a job).
The most popular database management concept is called Relational Database Management System or “RDBMS”. In a nutshell, it is a collection of programs and capabilities that enable users to create, update, administer and otherwise interact with a database. RDBMS stores data in the form of tables, with most commercial relational database Management systems using Structured Query Language (SQL) to access the database.
If you work in marketing, chances are you have to interact with either an IT department or third-party services such as MailChimp or Hubspot. You would be familiar with preparing or segmenting customer data. When IT is busy, many of us also have to write simple queries to pull the data ourselves. All of these actions happen under RDBMS database design. The database is designed using multiple tables as standard. The data is stored in lots and lots of tables, or ‘relations’. Those tables are divided into rows (records) and columns (fields).
Much like the relationships between data in an entity’s relationship diagram, the tables in the relational database can be linked in several ways:
- Characteristics of one table record may be linked to a record in another table
- A table record could be linked to many records in another table
- Many table records may be related to many records in another table.
Because there could be many tables in a database that linked together, some or many of us would have heart IT using the terms “Primary Key” and “Foreign Key”. A simple way to explain the difference between these two keys is a primary key that uniquely identifies a record in the table.
And, a foreign key is a field in the table that is a primary key in another table. IT developers use these keys to link different tables to pull data for us.
Database Normalisation
When I studied a database management course many years ago, I wonder how a database ends up having so many tables. What is the first step when a database programer is told to build a database? Does he come up with multiple tables in his head and draw them in a piece of paper. It turns out that there is a concept behind every database design. The concept is called normalisation.
Database Normalisation is a technique to organise data in the database. It is a systematic approach of decomposing tables to eliminate data redundancy(or repetition) and undesirable characteristics. The normalisation is a multi-step process that puts data into tabular form, removing duplicated data from the relation tables. Normalisation is used for mainly two purposes,
- Eliminating redundant(useless) data.
- Ensuring data dependencies make sense, i.e. data is logically stored.
So, when a database developer starts working on a new project, he is likely to come up with one or two big tables. Each table could have more than ten columns. He then applies the normalisation concept to break those big tables into many small tables to ensure that there is no redundant data. One of the apparent benefits of the database normalisation is the speed. When users make a query into a database, a properly normalised database will return results very quickly, with no duplicated data. I am sure many of us used to spend a lot of time exporting data into an excel file just to eliminate duplicated data.
Why should you care about the database concept?
I don’t know about you, but I value a (business) problem-solving skill very much. It is a vague claim when people say I have a good problem-solving skill. I am also proud of myself with this skill. But how do you justify the claim? My own version is I could solve many business problems because of my database knowledge.
Again, I am not a developer, and I cannot write programming codes. But I am not anxious when I see a lot of messy datasets. When I feel that something is not right, my habit is to download data to see what is in there. I am more frustrated if I don’t have a clear picture of the scope of what I am dealing with. It is very common for me to spend days to clean data and to create data definition. Many businesses make a simple mistake, or it’s just their ignorance to allow users to use different naming conventions in their databases. This simple ignorance creates a big challenge because it doesn’t allow you to map different datasets together.
And in the data preparation process, you learn insights about the issues you try to resolve. Those insights help connect different dots, which in turn help map out the scope of the problems that you are working on. Solving business problems is like sailing a boat in the ocean. If you only see the endless ocean line without seeing land, you will end up wasting your time finding and discovering nothing. The database knowledge is your lighthouse to get you out of that situation.
