Name database design notation you prefer and why?

Question

Which notation, methodology and tools for database designing, modeling, diagraming you prefer and why?
Which notation, standards, methodology

Answer 1

I prefer to use a three stage approach: conceptual data modeling, logical data modeling, and physical data modeling. The use of fancy tools depends on the scope of the project.

The first stage is analysis, also known as requirements definition. The result of the first stage is a conceptual data model, and related diagrams. The first stage is data model agnostic.

I use ER modeling and ER diagrams. Attributes are discovered, and their domains are determined, if possible. Attributes are connected to subject matter entities and relationships among entities. Relationships are identified, but not implemented via foreign keys. Later on, in logical design, the relationships will actually be implemented.

Natural keys are identified, and evaluated as to whether they can be trusted.

The notation involves attributes, domains, entities and relationships.

The second stage is logical design. The result of the second stage is a logical data model, expressed in SQL terminology. I use SQL terminology like columns, rows, tables, and domains, although these are stand ins for attributes, tuples, relations, and domains.
The logical model is specific to the relational data model, but is DBMS agnostic.

Unlike some practitioners, I use natural keys as PKs when they can be trusted. Otherwise, I invent surrogates.

The main difference is that foreign keys are now in the picture. Every entity gets a table. Some relationships are modeled by adding foreign keys to entity tables while other relationships get tables of their own. Many-to-many relationships are an example of the latter.

Issues like table composition and normalization are dealt with at this stage. Unlike some practitioners, I don't treat normalization as some kind of religion. I make design decisions in view of the consequences. However, departures from normalization have to have a specific justification.

if I were to design a non relational database, the second stage would look very different.

The third stage is physical design. This results in a physical data model. The physical data model starts with the logical data model, and adds features like indexes, tablespaces, stored procedures, and what have you. The physical design is DBMS specific, and takes into account volume, traffic, performance goals, and resources available.

The physical data model is a blueprint for database construction.