Hey everyone,

Is a database design based on Data Flow Diagram? Like, the number of datastores should be the same as the number of tables in the database?

Cheers,

Dani AI

Generated

Short answer: no — a DFD’s datastores are logical places where data is held from the process/view perspective, not a one-to-one instruction to create the same number of physical tables. DFDs show flow and persistence points; the ER (entity‑relationship) model is where entities, attributes, keys and relationships are defined and where the table design actually comes from.

The thread already points to both sides: is right that DFDs describe transformations and flow, and and are right to emphasize the ER model as the design basis. In practice you use the DFD as an input for identifying candidate data stores, then create a conceptual ERD (and data dictionary), then produce a normalized logical model before mapping to physical tables.

Common mapping patterns to keep in mind:

  • One DFD datastore → multiple tables (e.g., a single “CustomerRecords” datastore often becomes Customers, CustomerAddresses, CustomerContacts).
  • Multiple DFD datastores → one table when the diagram uses different names/process views for the same underlying entity (consolidate them).
  • Some DFD datastores are non‑relational (queues, logs, flat files, caches) and don’t map to permanent tables.
  • DFDs don’t list attributes or keys — build a data dictionary and ERD to capture those.

Practical workflow and tips: extract data elements from each datastore, build an ERD and normalize (3NF as a default), decide primary/foreign keys and indexes, then map entities to tables and document the mapping back to the DFD for traceability. Don’t blindly create N tables because a DFD shows N datastores — reconcile names, confirm unique identifiers and lifecycle with stakeholders, and only denormalize later for performance.

Recommended Answers

All 4 Replies

i think database design based on Data Flow Diagram because Data flow diagrams are used to describe how the system transforms information.

Since the DB Design is based on DFD, then it is true that the ER is based on DFD because the DB design is dependent on ER.

i think it is more precise to say that DB Design is actually based from ER, but the number of DB that you are going to use/create must match with the number of DB indicated in your DFD .. this is as far as i can remember

azareth is right DB is actually based from Entity relationship diagram

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.