Editor's introduction: The product information structure diagram helps to clearly display product information, and to a certain extent, it can provide a basis for uploading data in the background. However, many people may find the product information structure diagram difficult. This may be because they do not understand the database table structure, etc. caused by factors. In this article, the author summarizes the knowledge required for product information structure diagrams. Let’s take a look.

Foreword

Have you ever found it difficult to design a product information structure diagram, with no way to start and at a loss? What is the root cause?

The essential reason is that you simply don't have the concept of object-oriented and understanding of the database table structure in your mind.

Don't panic, Brother Zhu will help you explore the entire process of dismantling product information into objects and tracing it back to the bottom of the database to solve your doubts.

1. What is object-oriented?

In object-oriented programming, an object refers to a specific thing that can be seen and touched in real life.

It is actually a way of thinking that focuses on abstracting all the information you see into a container. This container can hold a lot of information and do many things, and this container is an object. For example, a car is an object. Its attributes include: model, color, and size; its methods include: carrying passengers, running on the road, etc.

Program Concept: A Java program can be thought of as a collection of objects that work together by calling each other's methods. Classes and objects are the core concepts of object-oriented methods. Object-oriented programming ideas have always strived to make the description of things in computer language as consistent as possible with the original appearance of the things in the real world.

Speak human language: Use computer language to describe everything in the real world.

• Class: A class is a template, which describes the behavior and status of a type of object. It is a description of a type of thing and is an abstract and conceptual definition.
• Object: An object is each individual entity of this type of thing that actually exists. It is an instance of a class and consists of attributes (synonyms: state, field) and methods (synonyms: behavior, function).
• Attributes: used to describe the characteristics of an object. Most of the field information we usually see on the page refers to this stuff.
• Methods: Describe the behavioral operations that an object can perform. Logical operations, data modification, and all actions are completed in methods.

2. What is a product information structure diagram?

Sort out the information that needs to be displayed for the entire product. It is generally considered to be the information that should be displayed on each page of the product through analysis and sorting. It also provides a basis for uploading data in the background.

Combined with object-oriented thinking: describe what objects and fields the product has. Abstract the page information you see into the dimension of an object, and then put the information of the same object together.

The information structure diagram drawn by our product people does not need to be exactly the same as the database table structure designed by the development students. Just extract it in a single object dimension according to your understanding.

3. What is a database?

A database is a "warehouse that stores and manages data according to certain rules." It is a collection of large amounts of data that is stored in a computer for a long time, is organized, shareable, and unified management.

In human terms: A database is actually a hard drive. You can store things in it and retrieve things from it.

I vaguely remember a passage in "Java Programming Thoughts" that everything in the world is an object. Very powerful and very reasonable. The database table structure is the embodiment of objects in programming language. When we do system design, we trace the bottom layer of the data, which is one object after another, and the relationship between objects (ER diagram).

1. Database concept

1. Database: Each table is identified by a name. A table contains columns with column names, and rows for recording data.
2. The essence of product design: it is nothing more than the addition, deletion, modification and query (CRUD) of various tables in the database.
3. Database types: They are divided into relational and non-relational. As for PM, we only need to understand the relational type.
4. Relational database = table structure + relationship between tables.
5. Relational database: A database based on the relationships between objects in real life. Mainstream relational databases: mysql, oracle, db2, sqlite.
6. Non-relational database: A relatively loose database that can be stored without strict structural specifications. It usually uses key-value pairs in json format to represent and store data. Mainstream non-relational databases: MongoDB, CouchDB. Application scenarios: Scenarios with relatively high access requirements and high concurrent processing.
7. sql: database operation language, which can add, delete, modify and query data tables in the database. Add insert, delete, change update, check select.

2. Ideas that product managers can apply to design

Table structure: Define the fields, types, primary keys, foreign keys, and indexes of a table. These basic attributes constitute the table structure of the database.

Product design scenario application: You only need to pay attention to which fields are in the current table. So when communicating with technology, you can summarize and abstract the information on the current page into a table. Each detail in the information is each field in the table.

Association relationships between tables (ER diagram): There are four types of relationships between tables [one-to-one, one-to-many, many-to-one, and many-to-many]. A little trick is usually to compare two objects, what is the relationship between A and B, and what is the relationship between B and A, so as to draw a conclusion.

1) Technical benefits: cascade deletion

What is the use of relationships between tables? There can be a joint relationship.

For example, there is a user table, an information table, and one user corresponds to multiple pieces of information. When you delete a user, will the user's information also be deleted? If there is no association, you have to manually delete the user before deleting it. Write a sql statement to delete the corresponding information in the information table. If it is related, there is no need. Just cascade deletion. As long as the user is deleted, the information under this user will be gone.

2) Product design scenario application: automatic matching of information from multiple channels

Background: I filled in some information on a certain page of channel A, and I had to fill in some similar field information on BCD pages of different channels, which was very time-consuming and labor-intensive.

Function: In order to improve human efficiency, I decided to design an automatic matching function. Is it one-to-one, one-to-many, many-to-one, or many-to-many?

After investigation, it was found that the A channel reference object and the BCD channel have a one-to-one relationship. Then I only need to design an ABCD channel relationship correspondence list, compare the reference of mainstream channel A with other channels, and then the system can automatically synchronize A's information to BCD.

PS: Database table, for product managers, I think it is good to understand its underlying principles. Being able to apply its technical principles to product design can make your thinking clearer (OMG, it turns out that my system It’s these tables that work, it’s so awesome, my technical guy).

4. Case analysis | The relationship between the three

Let’s take the car in the picture below as an example. It has different colors, brands, names and other information. We need to do product design for it. Its essence is from the product information structure diagram - objects - what is the bottom layer of the database? ? Let’s explore together.

Product information structure diagram: There is a car list management page, including color, brand, and name.

Object-oriented thinking: A car is a class, and each person’s car is an object of that class. The object contains the three attributes of the car: color, brand, name, etc.

Database table structure: There is a table with three fields: color, brand, and name.

It’s easy to understand by comparing it, right? So it’s not difficult. What’s difficult? The difficulty is how to abstract them into objects.

How can we have object thinking? Let's listen to the next chapter's analysis of abstraction, encapsulation, inheritance, and polymorphic thinking.

Summary

I hope your doubts have been resolved. Welcome to leave a message for in-depth communication.

Author: Zhu Ge gj, WeChat public account: Deliberately practice product thinking (ID: kylxpm520)

This article was originally published by @庄哥gj on Everyone is a Product Manager. Reprinting without permission is prohibited.

The title picture comes from Unsplash, based on the CC0 agreement