Your question focuses on tooling.
To get started:
Figure out what your application is supposed to do, what it is supposed to accomplish, what actions/interactions are going to be supported.
Now decide what persisted data is needed to support all your scenarios. If you can think of the data that your queries will have to return you’ll have a first draft of the data that you need. Now aggregate that knowledge and convert it to a relational model.
There really is nothing stopping you from laying down that foundation with a pen and paper or whiteboard + marker + camera (to capture snapshots).
If you are finding it difficult to break down your data into a schema:
Joe Celko’s Data and Databases (1999) - 2.6 Semantic Methods p.23
Another approach to database design that was invented in the 1970s is based on semantics instead of graphs.his book for details of the method. What I do not recommend is using the diagrams in his method. In addition to diagrams, his method includes the use of simplified English sentences to express relationships . These formal sentences can then be processed and used to generate schemas in a mechanical way.
Most of the sentences are structured as subject-verb-object, but the important thing is that the objects are assigned a role in the sentence. For example, the fact that “Joe Celko wrote Data and Databases for Morgan Kaufman Publishers” can be amended to read 'AUTHOR: Joe Celko wrote BOOK: ‘Data and Databases’ for PUBLISHER: Morgan Kaufman," which gives us a higher level, more abstract sentence that “Authors write books for publishers” as a final result, with the implication that there are many authors, books and publishers involved. Broadly speaking, objects and entities become the subjects and objects of the sentences, relationships become verbs, and the constraints become prepositional phrases.
A major advantage of the semantic methods is that a client can check simple sentences for validity easily. An ER diagram, on the other hand, is not easily checked. One diagram looks as valid as another, and it is hard for a user to focus on one fact in the diagram.
Terry Halpin - Object Role Modeling: An Overview (2001) Terry Halpin - Object Role Modeling: An Overview (pdf) Terry Halpin - Information Modeling and Relational Databases. Chapter 3: Conceptual Modeling: First Steps (2001)
Re-emphasizing: Don’t do the full 7 steps of the CSDP (Conceptual Schema Design Procedure) - do just enough to get the facts and sentences .
These capabilities may require the interchange of information — shared models — but I have seen too often that thinking about data leads to anemic, CRUD-based (create, read, update, delete) services. So ask first “What does this context do?”, and then “So what data does it need to do that?”
Sam Newman, Building Microservices (2015)
3 Likes
