Database Design Concept Workshop is a hands-on workshop in relational database design, from analysing requirements and drawing ER diagrams to turning them into table structures, checking them with normalisation and creating the tables with constraints on PostgreSQL. It suits developers, database staff and systems analysts who already know some SQL.
Many problems in business systems start with the database structure: duplicated data that is changed in one place but not another, reports that pull figures that do not match, or systems where new features are hard to add because the tables were related wrongly from the start. Conceptual design with the entity relationship model, followed by turning it into table structures that have been checked for quality, keeps a database correct, easy to maintain and ready to grow, whichever DBMS or framework you use.
This hands-on course starts with the relational model, keys and data integrity, then analyses requirements and business rules, draws ER diagrams in Crow's Foot notation along with patterns common in real systems, turns them into table structures, checks them with normalisation up to 3NF and BCNF, and creates them with CREATE TABLE and constraints on PostgreSQL 18. It closes with checking design quality and a workshop designing a system from a real brief from start to finish.
Course Details
This course is the 2026 edition of Database Design Concept Workshop, rewritten to cover every step of the database design process. It runs for 2 days, 6 hours per day (12 hours in total, 09:00-16:00), as lectures with labs and workshops built around a training registration case study, at Beginner to Intermediate level. Day one covers the relational model, keys, data integrity, requirements analysis and ER diagrams. Day two practises mapping to tables, normalisation, creating tables with constraints on PostgreSQL 18 and checking design quality. The principles apply equally to MySQL, MariaDB and SQL Server. Learners take home ER diagram files, SQL scripts and a design quality checklist.
Section 1: Lab: Database Systems and DBMSs Today
Section 2: Lab: The Relational Model, Keys and Data Integrity
Section 3: Workshop: Requirements and Business Rules
Section 4: Lab: Drawing ER Diagrams
Section 5: Lab: ER Patterns Common in Real Systems
Section 6: Lab: Turning ER Diagrams into Table Structures
Section 7: Lab: Normalisation
Section 8: Lab: Physical Design with CREATE TABLE
Section 9: Lab: Checking Design Quality
Section 10: Workshop: Designing a Database from a Real Brief
No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770
An entity relationship (ER) diagram shows a database's structure at the conceptual level before any tables are built. It has three main parts: entities, the things you store data about, such as customers, products or orders; attributes, the properties of each entity, including a primary key that identifies each record uniquely; and relationships between entities, with their cardinality: one-to-one, one-to-many or many-to-many. Crow's Foot notation is the most common way to draw them today.
Normalisation splits data into tables to reduce duplication and avoid problems when inserting, updating or deleting. 1NF requires each field to hold a single value with no repeating groups. 2NF adds that every non-key column must depend on the whole primary key, not just part of a composite key. 3NF requires that non-key columns do not depend on other non-key columns, so a province name is stored in its own table rather than repeated in every customer row.
Turn each entity into a table and each attribute into a column, choosing a primary key for every table. Then map the relationships: for one-to-many, put the primary key of the one side as a foreign key in the many side; for many-to-many, create a junction table holding foreign keys to both; for one-to-one, place a unique foreign key on either side. Finally, check the design with normalisation before writing the CREATE TABLE statements with their constraints.
Identity number keys are small, easy to read and suit most systems. UUIDs suit cases where IDs are generated by several systems or should not be guessable, but they take more space. Version 7 UUIDs are time-ordered, so they work better with indexes than random ones, and PostgreSQL 18 provides a uuidv7 function. Whichever you choose, keep business codes such as customer numbers in a separate UNIQUE column.
It suits developers, staff who look after or work with databases, systems analysts and students who need designs that work without problems. You should be able to use a computer and a database at a basic level, know some SQL, and be able to install software on your laptop. The principles apply to PostgreSQL, MySQL, MariaDB and SQL Server.
Yes. It can be run in-house for your team, with examples adapted to your own work, such as practising on the systems or data your organisation actually uses. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.
Much of the work in organisations that run Oracle Database involves multi-step data processing, such as payroll calculations, end-of-day closing or moving data between tables. Written as one SQL statement at a time from the application side, this work is…
SQL Server is one of the most widely used databases in Thai organisations, behind accounting, sales and internal systems. Anyone starting to work with data needs to create tables, write SQL to pull data into reports and bring Excel data into the system. Yet…
People who can already write some SQL soon meet questions that a plain SELECT and JOIN cannot answer, such as ranking sales within each region, comparing with the previous month, calculating running totals or reading JSON from another system. The result is…
