Это зависит от того, где ваши сильные стороны и куда вы хотите пойти.
Вы можете начинать с объектов и выполнять довольно хорошую работу, включая хороший дизайн таблиц в вашей базе данных, если вы начинаете в нужном месте.
Начните с объектно-ориентированного анализа, а не объектно-ориентированного проектирования. Я не могу особо подчеркнуть разницу между анализом и дизайном. Люди, которые пишут об объектно-ориентированном анализе, некоторые из которых используют UML в качестве инструмента, стараются четко провести это различие. Анализ относится к проблемной области, а дизайн относится к области решения. Они могут легко смешиваться друг с другом, независимо от того, является ли ваш подход объектно-ориентированным или нет.
Если вы проведете хороший OOA-анализ требований вашего проекта, вы, вероятно, сможете сделать разумную работу по построению концептуальной модели данных параллельно и синхронизации этих двух данных друг с другом. Когда вы создаете концептуальную модель данных, я предлагаю вам придерживаться модели, подобной модели ER.
Модель ER не скажет вам, как проектировать вашу базу данных. В этом весь смысл. Способ, которым вы отделяете проблемы анализа от проблем проектирования при моделировании данных, заключается в том, чтобы выполнить анализ с использованием моделирования ER, а проект - с помощью моделирования реляционных данных, по крайней мере, в начале.
Отображение между OOA и ER достаточно просто, чтобы вы могли управлять двумя моделями параллельно. Там могут быть новые инструменты, которые управляют обоими типами моделей для вас. Отображение между ER и RDM обманчиво просто. В простейшем сопоставлении вы превращаете каждую сущность в таблицу, основанную на идентичности сущности, а каждое отношение - в отдельную таблицу, основанную на внешних ключах, которые ссылаются на сущности. Можно и желательно уменьшить количество таблиц, подключив некоторые внешние ключи к таблицам сущностей, но это деталь.
Из OOA вы переходите к OOD для проектирования и OOP для программирования.
От ER для концептуального моделирования данных вы переходите к RDM для логического моделирования данных и к своему специфическому для СУБД диалекту SQL для физического моделирования данных. Определенно, есть инструменты, которые помогут вам в этом, если ваш проект слишком велик для моделирования на бумаге или белой доске.
Периодически вы создаете то, что у вас есть, может быть, с заглушками для не построенной части, и вы
согласовать дизайн приложения с дизайном базы данных. Если вы хорошо поработали, в конце дня вы должны быть в хорошей форме.
Если вы разрабатываете одну базу данных и несколько приложений одновременно, все становится действительно интересным.