The Application Approach to Database Design

The previous lesson covered the subject approach: designing a database around the core, real-world subjects a business deals with, independent of any one application. This lesson covers the alternative: the application approach, which designs the database around the specific application that will present and use the data.

The application approach is a bottom-up design because it focuses first on how data will be viewed, on screen, in a report, or in some other specific document, and only secondarily on how that data should be organized. The database is designed to fit the application, rather than the application being built on top of an independently designed subject model. Designers either build a new application or adapt an existing one to present and organize the data exactly the way that one application needs it.

This can work well for a single, well-understood application. If an order-entry screen needs customer address details, order lines, and warehouse shipping codes all in one place, a designer working application-first will often build tables that populate exactly that view quickly and directly. Picture a version of Stories on CD, Inc. built this way: a designer tasked only with "build the order-entry screen" might reasonably combine customer name, address, and every ordered CD title into one wide table, since that is everything the screen needs to display, and nothing about that table is wrong for that one purpose.

The trouble starts once a second application enters the picture. If, going back to that hypothetical order-entry table, Stories on CD later needed a separate distributor-management application, also built application-first, the organization would end up with two independently designed representations of overlapping data, the order-entry screen's own version of customer and CD details, and the distributor application's own version of the CDs it tracks. Each application maintains its own version of the truth, updates do not propagate between them, and reconciling the two later is expensive. In a larger organization with more departments than a small mail-order company, the same pattern plays out at a larger scale, a separate billing system, marketing system, and support system each inventing their own version of "customer":

[Billing UI]    --> [Billing Database] (Contains Customer, Invoices)
[Marketing UI]  --> [Marketing Database] (Contains Customer, Campaigns)
[Support UI]    --> [Support Database] (Contains Customer, Tickets)
                     ^
            Data duplicated and fragmented across silos

The subject approach avoids exactly this problem, by identifying Customer, Product, and similar core entities once, independent of any single application, and letting every application, present and future, build on that same shared foundation:

The two approaches differ along several dimensions at once, not just in where the design process starts:

Dimension	Application Approach (Process-Driven)	Subject Approach (Data-Driven)
Primary driver	Specific programs, screens, forms, or departmental tasks	Core real-world business subjects (Customer, Product, Order)
Scope	Localized to a single application or immediate workflow	Enterprise-wide, serving multiple current and future applications
Design perspective	Outside-in: the interface or process dictates the table structure	Inside-out: business rules and the data itself dictate the schema
Redundancy	Often high; schemas are denormalized to optimize one specific screen or query	Low; normalized toward 3NF or BCNF, one source of truth per subject
Flexibility	Brittle; a process change or new application often forces a schema rewrite	Resilient; new applications adapt to a stable entity model
Integration	Data silos, conflicting definitions, costly synchronization between systems	A shared data layer with standard definitions across the organization

The subject approach, the top-down approach this course focuses on, is closely associated with Information Engineering, a methodology developed by James Martin in the 1980s built explicitly around identifying an organization's core "subject areas" before any individual application is designed. That history is part of why the terminology in this course, subject area, subject approach, has stayed consistent for decades: the underlying problem it solves, applications multiplying faster than anyone can keep their data definitions in sync, has not gone away.

None of this means the application approach is never the right call. It remains useful for throwaway prototypes, highly isolated edge-computing scenarios, or a small, hyper-specialized tool where getting one interface to market quickly outweighs long-term integration concerns. What it is not well suited for is anything meant to last, or anything more than one application will eventually need to touch. For that reason, the subject approach remains the most common approach to database design, and the one this course focuses on.

The terms "top-down" and "bottom-up" show up in a second, broader sense too, describing how a systems analyst gathers requirements in the first place, not just which database design approach the analyst ends up choosing. The two senses are related, but worth keeping distinct.

In the general top-down strategy, the analyst starts from the big picture, an overall sense of what the system needs to accomplish, and works with end users to determine, in that context, what data should be kept in the database. This requires the analyst to already have a fairly detailed understanding of the system as a whole; done poorly, a top-down analysis can miss something important simply because nobody thought to ask about it from the top down.

In the general bottom-up strategy, the analyst instead starts from specific details already in front of them: the existing reports, screens, and forms the organization uses today, and works backward from those concrete artifacts to determine what data must be stored to support them.

A few everyday examples illustrate the general pattern. Statistical analysis is bottom-up: a sample from a small population is examined first, and the results are then inferred for the overall population. Medical diagnosis is bottom-up in the same way: a physician examines specific symptoms first and works toward a general diagnosis. Project management and engineering tasks tend to run top-down instead: a car manufacturer starts from overall specifications, a target price, a target fuel economy, seating for a given number of passengers, and only then drills down into the detailed design decisions needed to meet them.

This broader distinction is exactly why the subject approach is described as top-down and the application approach as bottom-up: the subject approach starts from the big picture of what the business fundamentally deals with, while the application approach starts from the concrete details of one interface and works backward. In practice, an analyst following either approach will still talk to users and often build prototype reports, screens, or forms to help those users visualize what the finished system will do; that part of the process does not change. What changes is whether the data model is allowed to be shaped by any one of those prototypes, or is kept independent of all of them.

A short recap of this lesson:

• The application approach designs a database around one specific application's needs, screen layouts, reports, forms, which is why it is described as bottom-up.
• It works well for a single, isolated application, but tends to produce data silos and conflicting definitions the moment a second application needs overlapping data.
• The subject approach avoids this by identifying core business entities once, independent of any application, and letting every current and future application build on that shared model.
• "Top-down" and "bottom-up" describe both the specific subject-versus-application choice in database design, and the broader, related question of how an analyst gathers requirements in the first place, starting from the big picture, or starting from existing screens and reports.
• The application approach still has a place, for prototypes and small, isolated tools, but the subject approach remains the default for anything meant to last.

The next lesson examines the overall architecture of databases.