inflearn logo
inflearn logo

Easy to Learn Data Modeling: From Basics to Practical Table Design (DASP/DAP)

Have you ever felt frustrated with table design? This course is for those who have had concerns like, "Is this table right?", "Which column should be the PK?", "Is it okay to connect relationships this way?", or "Will I have to rebuild the table when adding new features?"

(5.0) 2 reviews

11 learners

Level Basic

Course period Unlimited

SQL
SQL
DBMS/RDBMS
DBMS/RDBMS
ERD
ERD
database-modeling
database-modeling
Data Architecture Semi-Professional
Data Architecture Semi-Professional
SQL
SQL
DBMS/RDBMS
DBMS/RDBMS
ERD
ERD
database-modeling
database-modeling
Data Architecture Semi-Professional
Data Architecture Semi-Professional

What you will gain after the course

  • How to analyze requirements and design tables

  • Essential concepts of 'Logical Data Modeling' regarding entities, attributes, identifiers, and relationships

  • Knowledge for obtaining DASP and DAP certifications

  • Table design methods considering performance

  • Notations for drawing ERDs (IE, Barker)

Is your table design okay?

  • The anxiety of not being sure every time you design.

  • A complex structure that is already tangled when you try to modify it đã bị rối tung lên rồi

  • The cycle of adding features = redesigning tables

  • Data modeling that you have never learned systematically


In this course, you will learn how to design tables that are not just 'functional,' but
scalable and easy to maintain.

Concerns everyone faces in practice

Creating a table that properly reflects customer requirements is not easy.
It is difficult to judge on your own which structure is appropriate, whether the design is easy to modify, or if the structure is scalable.

Even when searching for answers, every situation is different, and in the end, the anxiety of wondering "Is this the right way?" only grows.

Design problems only grow larger as time passes.

It seemed fine at first...

Many developers have similar experiences.
In the early stages of a project, the focus is on quickly creating tables and implementing development features.
Since there is little data and requirements are not extensive, everything feels like it's going smoothly.

However, as time passes and the project grows and becomes more complex,
the table structure created "only for speed" in the early stages becomes an increasingly large obstacle.

Even simple feature additions require modifying multiple tables, bugs recur due to data consistency issues, and
eventually, you end up regretting it, thinking, "If only I had designed it properly back then..."


Initial Stage

😊

  • "As long as it can hold the data for now, it's fine!"

  • Designing without deep consideration

    Cramming all necessary attributes into a single table for the sake of rapid development

  • When the data volume is small, it seems to have no problems


6 months later

📉

  • Every time a feature is added, the table structure needs to be modified

  • The same data is duplicated across multiple tables, causing consistency issues

  • Queries become increasingly complex and performance starts to slow down

After 1–2 years

🚨

  • There are too many places that need to be modified just to add a single feature

  • Always worrying about which table to get the necessary data from

  • Data inconsistency occurs frequently, and it takes a lot of time to fix


Solution: Proper Data Modeling (Table Design)

Same requirements, different designs

Even when implementing the same functionality, the results vary completely depending on how you design it.
A table designed with scalability in mind can easily adapt even when requirements change.

On the other hand, tables created without deep consideration require numerous modifications even for minor changes and lead to continuous unexpected issues.

In the beginning, these differences aren't very visible. Both seem to work just fine.
However, as time passes, the difference manifests in development speed and maintenance difficulty.

This course covers how to design scalable tables.
You will learn how to build it "right from the start" rather than saying "I'll fix it later."
By the end of the course, you will be able to look at requirements and design them into a scalable structure.


📌Customer Requirements📌

  1. At the cafeteria, you can check the weekly menu.

  2. Lunch and dinner are provided from Monday to Friday, and for each meal plan

    Information about the nutritionist who provided the meal plan can be checked.

  3. Rice and soup must be included in the meal menu, and multiple side dishes can be included.

    Calories must also be managed.

  4. In some cases, side dishes such as yogurt, ice cream, and fruit are also served.

👎A model designed without much thought

👍A model designed with sufficient consideration

Features of this course

1. Practical-focused learning

Composed of content that can be applied directly in practice, rather than just simple theory

  • Presentation of common real-world challenges and their solutions

  • Use of practical examples such as book rental systems and shopping malls.

  • Learn by following the data modeling stages step-by-step.

2. Systematic Lecture Materials

Perfect review with 700 pages of PPT materials

  • Easy to grasp concepts with content summarized to the core

  • A reference you can look up anytime

3. Easy Practice for Everyone

Start immediately without any special preparation

  • Paper and pen are enough; tools are optional.

  • Practice using the web-based ERD Cloud without any separate installation.

  • Explaining both Barker notation and IE notation

Course Composition (Detailed Table of Contents)

1. Starting the Data Modeling Basics Lecture

Course Introduction: Have you ever felt frustrated during the table design process?

  • What is covered in the course

  • Who is this course for? (Feat. Developers and novice modelers who need DB design)

  • Lecture Curriculum

  • Prerequisite knowledge for taking the course


How to improve work efficiency and development productivity

  • What is data modeling?

  • We are not managing ERDs.

  • If you design it this way, you will suffer later.

Checking my understanding of data modeling

  • Quiz 1: True/False Questions

  • Quiz 2: Matching the number of tables

2. The First Step for Data Modeling

Steps from requirements analysis to table creation

  • Data modeling steps explained through a toy project

  • Requirements Analysis/Definition

  • Setting Subject Areas

  • Conceptual Data Modeling

  • Logical Data Modeling

  • Physical Data Modeling

  • Can the data modeling stages be simplified?

Data Modeling Notations (Barker, IE)

  • Barker/IE Notation for Data Modeling

  • Entity Notation

  • Attribute Notation

  • Identifier Notation

  • Relationship Notation

  • Subtype notation

Data Modeling Tools (ERwin DA# ERDCloud)

  • ERwin DA# ERDCloud

  • ERDCloud Practice

3. Entity [Table]: What information should be derived as a table?

What is an Entity?

  • Entity Concept

  • Table? Entity? What's the difference?

How to derive entities from requirements

  • How should entities be derived?

  • The core of data modeling: 'Entity Derivation'

  • [Practice] Following the Entity Derivation Process

Checking if entities have been 'properly' identified

  • Whether a clear meaning has been assigned to the entity

  • Whether it is an object that requires management

  • Whether it forms a set

  • Whether it is dependent on the business process

  • Whether it possesses independence

  • Whether entities were derived based on each individual screen

By classifying entities, you can understand what kind of data is being stored

  • Entities also have distinct characteristics.

  • The secret to excellent table design: Classifying entities by their characteristics

  • Benefits of Entity Classification

4. Attributes [Columns]: Not all columns in the requirements are added.

What is an Attribute

  • Concept of Attributes

  • Components of an attribute

Attribute classification that makes query development easier

  • Reasons for classifying attributes

  • Basic Attributes

  • Relationship Attributes

  • Derived Attributes/Redundant Attributes

  • System Attributes

Special attribute design that many developers miss

  • Special Attributes

  • Multivalued Attribute

  • Composite Attribute

  • Exclusive Attributes

  • Code Attributes

Attribute Derivation Method

  • Secrets to finding the attributes you truly need

  • [Practice] Following Along with Attribute Derivation

5. Identifier [PK]: Select these types of columns as PK.

What is an Identifier

  • Concept of Identifiers

  • Characteristics of Identifiers

  • Classification of Identifiers

Artificial identifiers frequently used as 'OO Number'

  • Natural Identifiers and Surrogate Identifiers (feat. Real Subject and Dummy Subject)

  • Identifiers commonly used by entity type

  • Should we use natural identifiers or surrogate identifiers?

Identifier Selection Method

  • [Practice] Following the Identifier Selection Process

  • Precautions when selecting identifiers

Various stories related to identifiers

  • What if we unconditionally use artificial identifiers?

  • Product Number Attribute Formats (000000121 vs GOD000121 vs 121)

  • The habit of thinking about case data

6. Relationship [FK]: Connection between tables - Join

What is a Relationship?

  • Concept of Relationships

  • Relationships and Joins

Components of a Relationship (Relationship Degree, Relationship Optionality, Relationship Name)

  • Components of a Relationship

  • Relationship Cardinality (1:1 / 1:M / M:N)

  • Relationship Optionality (Optional / Mandatory)

  • Relationship Name

The secret to connecting relationships easily

  • The hidden meaning behind relationship lines

  • Dependent Relationship

  • Referential Relationship

  • Identifying and Non-identifying Relationships

  • Summary of Dependent/Reference and Identifying/Non-identifying Relationships

Tricky relationships encountered in practice (Multiple, Recursive, Exclusive, BOM)

  • Various Relationships

  • Multiple Relationships

  • Recursive Relationship (= Circular Relationship)

  • Exclusive Relationship (= Arc Relationship)

  • BOM Relationship

Relationship Derivation Method

  • [Practice] Following Relationship Derivation 1

  • [Practice] Following Relationship Derivation 2

Various stories related to relationships

  • Do we need Foreign Key (FK) constraints? (feat. My company doesn't create FKs)

  • Cases where you don't need to connect relationship lines

  • Connecting relationships for performance enhancement

7. Subtypes: How to Strategically Manage Similar Entities

Subtype and Supertype

  • Concepts of Subtype/Supertype

  • Subtype/Supertype Characteristics

In what situations should subtypes be used?

  • Reasons for using subtypes

  • Situations where subtypes should be derived

How to Derive Subtypes

  • [Practice] Following the Subtype Derivation Process

  • Precautions when deriving subtypes

Creating tables for entities containing subtypes

  • 3 types of table creation for entities including subtypes

  • Type 1. Subtype Structure

  • Type 2. Integrated Table Structure

  • Type 3. Individual Table Structure

  • Criteria for selecting table creation types

8. Normalization and Denormalization: Perfect Structure vs. Fast Performance

What is Normalization

  • Concept of Normalization

  • Normalization: Why should we do it?

  • Advantages and Disadvantages of Normalization

First Normal Form (1NF) - Let's separate duplicates!

  • Definition of 1st Normal Form (1NF)

  • Problems when 1st Normal Form (1NF) is not applied

  • [Practice] Shall we improve it?

2nd Normal Form (2NF) - Ensure full functional dependency on the entire primary key!

  • Definition of 2nd Normal Form (2NF)

  • Problems when 2nd Normalization is not performed

  • [Practice] Shall we improve it?

3rd Normalization - Are there dependencies between non-identifier attributes?

  • Definition of 3rd Normal Form (3NF)

  • Problems when 3rd Normal Form (3NF) is not applied

  • [Practice] Shall we improve it?

What is De-normalization?

  • Concept of Denormalization

  • Essential! Checklist before performing denormalization

  • Advantages and disadvantages of denormalization

3 Denormalization Methods for Performance Improvement

  • Creating duplicate columns

  • Creating Duplicate Tables

  • Table Partitioning

9. Common Code and History Management

Common Code

  • What is a common code?

  • Reasons for using codes

  • Precautions when designing common codes

Common Code Design Method

  • [Practice] Common Code Design Method 1

  • [Practice] Common Code Design Method 2

  • Common Code VS Individual Code

History Management

  • What is History?

  • History management is essential in OO situations.

  • [Practice] History Design Method 1

  • [Practice] History Design Method 2

Recommended for
these people

Who is this course right for?

  • 'Developers' who need DB table designs for each business domain

  • A 'novice modeler' who needs to perform data modeling while considering the overall structure

  • For those aiming to obtain DASP or DAP certifications!

Need to know before starting?

  • The concept of Joins in SQL

  • Basic understanding of Select ~ From ~ Where queries

Hello
This is Archix

Hello 👋

I am Archix, working as a Data Architect at a foreign company.

Starting as a back-end developer, I earned SQLP 🎖 and DAP 🎖 certifications to pursue a career as a data expert. Currently, I work to improve data management by supporting developers with data model optimization and query tuning.

Through my experience with various projects and operations, I have come to realize one thing clearly: a system with a solid design does not falter. On the other hand, a poorly designed system suffers from recurring minor issues, which ultimately leads to a waste of unnecessary resources.

Having worked as a developer, I have experienced these situations firsthand, and I aim to incorporate those experiences into this lecture to provide content that can be applied immediately in practice.

I plan to continue my activities to promote the importance of data modeling in various fields.

If you have any questions about the DA role or your career after completing the course, please feel free to contact me at the email address below along with your "Course Completion" certification. I will do my best to help you as much as I can.

📩cherish1058@naver.com

Thank you.

More

Curriculum

All

37 lectures ∙ (9hr 42min)

Course Materials:

Lecture resources
Published: 
Last updated: 

Reviews

All

2 reviews

5.0

2 reviews

  • bbyyydd님의 프로필 이미지
    bbyyydd

    Reviews 5

    Average Rating 4.6

    5

    100% enrolled

    There are times when I design tables during development, and after listening to the lecture, many of my uncertainties seem to have been resolved. Above all, I struggled with writing queries due to poor table design, so it’s comforting to hear that it wasn't because of my lack of query-writing skills ㅠㅠ

    • cherish10588578
      Instructor

      I'm glad the ambiguous parts have been resolved. Queries for poorly designed tables tend to use many inline views, and with so much similar data, it becomes a struggle to figure out where to pull the information from. I'm sure you'll be able to create well-thought-out and well-designed structures in the future! Thank you.

  • cherish10588578님의 프로필 이미지
    cherish10588578

    Reviews 2

    Average Rating 4.0

    5

    100% enrolled

    Similar courses

    Explore other courses in the same field!

    Limited time deal

    $40.70

    33%

    $61.60