9 docs tagged with "design"

何をもって「通った」とするかで、テストが壊れるタイミングが変わります。状態検証と相互作用検証という 2 つの流儀と、どこから書き始めるかという方向の関係を扱います。

This chapter builds up, step by step for junior engineers, the idea of normalization for eliminating data duplication and contradictions (update, insertion, and deletion anomalies) — from functional dependency, through first to third normal form, a note on BCNF, and selective denormalization for performance.

This chapter shows junior engineers, through two examples — a restaurant order slip and an internal SNS — the end-to-end process of extracting entities from a form or business requirements, building an ER diagram, normalizing it, and reaching CREATE TABLE.

Through two comprehensive case studies — a "product delivery management system" and a "task management system" — this chapter practices the full flow of requirements → ER diagram → table definitions → expected queries, integrating the concepts learned across earlier chapters as the capstone of this guide.

This chapter explains why database design plays a role like a building's foundation, the qualitative reasons it's hard to fix later (you can't stop a live service, data-migration costs, the breadth of impact), and why data-design skills remain valuable even in the AI era.

This chapter explains, for junior engineers, where database design fits within the overall flow of system development, and how the conceptual, logical, and physical design stages move from abstract to concrete.

A practical guide for junior engineers just starting to design DB schemas for an API backend or a business application. Across 19 chapters plus a glossary and a design template collection — Part 1 Fundamentals → Part 2 Design → Part 3 Applied → Part 4 Practice — you'll learn to go from requirements through ER diagrams and table definitions to SQL, by reading straight through.

This chapter classifies the results of a process into normal, near-normal, and abnormal paths and explains handling for each. It covers the criterion separating expected from unexpected failures, when to use exceptions vs. return values, where to catch, and what to tell users and logs.

テストが書きにくいとき、それはコードの何を指しているのかを 5 つの型に分けます。型ごとに、テスト側で歪める対処と設計を直す対処を並べます。