Member Avatar for loveforfire33

im making a ASP.NET web application using a serverside database.
Hi :),
im making a ASP.net web application with a sqlserver backend database.

i have been requested to provide both UML and ERD/Normalization

i can do both of these techniques individually to a reasonable standard, however i am unsure about how they relate to each other?

for example if i do UML class diagrams first, does that mean all of the attributes in the class have to be in the same DB table?

if i do the normalization first i dont see how that helps with the UML?

The way im thinking of it at the moment is that the UML is just a way of sorting out the C# classes in ASP.net, and has nothing to do with the storage of the data (and therefore the ERD/normalization), and while classes may have several attributes - they dont need to be in the same table in the RDBMS - does that sound anywhere near right?

thanks :)

  • 3 Contributors
  • 3 Replies
  • 295 Views
  • 5 Days Discussion Span
  • Latest Post Latest Post by griswolf

Dani AI

Generated

Short practical answer: UML is a domain/design view and ERD/normalization is the persistence view. They are complementary and should be reconciled, not forced into a strict 1:1 mapping. A UML class’s attributes do not have to live in a single table. ’s intuition is on the right track, is correct that the concerns are different, and is right that the choice of starting point depends on whether the system is data‑centred or behavior‑centred.

Common mapping patterns to keep in mind:

  • Identity: entity classes usually map to a table with a primary key; value objects (no identity) often become columns on the owning table.
  • 1:N: map to parent and child tables; the FK sits on the “many” side.
  • N:N: implement a junction table (optionally with attributes of the relationship).
  • 1:1: store in the same table when always present; use a separate table when optional, large, or different lifecycle/permissions are required.
  • Inheritance: choose a strategy (single table with discriminator, table-per-type, or table-per-concrete) based on query patterns and null/join tradeoffs.
  • Large or historical data (attachments, audit rows): put in separate tables or external storage.

A practical iterative workflow: model the domain first to capture business rules and mark which attributes are transient, value objects, or entities; derive a normalized logical ERD from those entities and multiplicities; pick concrete mapping strategies (keys, FKs, inheritance mapping, indexes) and denormalize only where query performance justifies it; annotate the UML with persistence stereotypes (<<entity>>, <<valueObject>>, <<transient>>) or keep a separate persistence model; iterate with sample queries and ORM mappings and record the tradeoffs.

When targeting ASP.NET + SQL Server, use an ORM to reduce boilerplate but be explicit about mapping choices (table strategy, owned/value types, join tables). Document decisions so the domain model remains clean and the persistence design stays maintainable.

Recommended Answers

All 3 Replies

Member Avatar for griswolf

That sounds about right to me. If the program is data centered (as is probable in this environment), start with the data design, normalize the schema, and see how that affects your UML layout. Or vice versa if the program is calculation centered.

Most web services deal with an MVC architecture where the Model is the data (ERD used here), the View is as set of slices through the data (and the UML may be interesting here) and the Controller is most often a set of legal changes implemented over the data seen in a particular view.

Member Avatar for drjohn

ERD/normalisation are for database design. Nothing to do with programming - totally independent of it in fact.

UML is for object orientated design. To do with programming.


Two different subjects.

Member Avatar for griswolf

I guess drjohn has a much more restricted view of "programming" than I do. A well designed schema makes it ever so much easier to create the rest of the application than would be possible with a chaotic or 'it just grew that way' schema.

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.