Блог Александра Божко
Архивы
Рубрики

ER Studio

Вдогонку к предыдущему посту. Вопрос об именах таблиц.

Попытаюсь объяснить логику.

Если соблюдать все рекомендации по разработке приложений, то начинать следует с модели предметной области. Существует несколько разных подходов к моделированию и разных видов моделей. Остановимся на одном из самых популярных видов – ER модели, предполагающей определение сущностей и связей между ними. Обычно имена сущностей выражаются существительным в единственном числе.

Собственно, давайте определимся с этими сущностями и связями в нашей задаче. Думаю я на русском, поэтому сначала выделим и обзовем сущности по-русски.

Как процесс выглядит в реальности (без автоматизации)? Я беру лист бумаги и записываю на нем список продуктов, возможно с указанием их количества. С этим листом бумаги я иду в магазин и отмечаю, что куплено, что нет.

Очевидно, что первой сущностью будет сам ПРОДУКТ. Ведь набор наименований продуктов, в принципе, конечен. Да и при автоматизации процесса их удобно выбирать из предустановленного списка.

Я берусь утверждать, что сам листок с записями так же следует выделить в качестве сущности. Я завел машину и тут мне позвонил сосед. Ты, мол в супермаркет? Купи мне пиво и хлеб (с)… И я беру второй лист бумаги и пишу: “Продукты для соседа”. Ставлю дату (вот уже два атрибута у сущности!) и записываю чего он там хочет… Как означить эту сущность? СПИСОК ПРОДУКТОВ – плохая идея. Хотя бы потому, что набор экземпляров сущности ПРОДУКТ тоже а некотором смысле список продуктов. Поэтому более удачным названием будет СПИСОК ПОКУПОК (насколько может быть удачным имя сущности, содержащее слово СПИСОК).

Но нам потребуется и третья сущность. По идее, две первые сущности связаны отношением много-много, и на уровне логической модели ничего добавлять не надо. Но, у нас завис такой атрибут как количество покупаемого продукта. Поэтому вводим сущность, соответствующую записи в списке покупок. И опять логично бы было назвать эту сущность СПИСОК ПРОДУКТОВ и опять это не совсем хорошая идея. Я просто решил обозначить эту сущность комбинацией имен связанных сущностей – СПИСОК ПОКУПОК – ПРОДУКТ. А, поскольку это не совсем удобочитаемо, то просто – СПИСОК-ПРОДУКТ.

Возможно, название ПУНКТ СПИСКА ПРОДУКТОВ (Shoping List Item) тоже имеет право на существование.

ERModel

Теперь на основе полученной модели надо создать таблицы. Естественно, что их имена должны либо транслитерироваться, либо переводиться. Я выбрал последний вариант.

Product, ShopingList, List_Product.

По сути, все “правила” именования сущностей и таблиц носят исключительно рекомендательный характер. И говорить о том, что они названы правильно или не правильно, не совсем корректно. Основной критерий здесь, на мой взгляд, удобство.

Ну, и в контексте данного поста напомню о DB Meta Studio – утилите, которая позволяет вставлять в код элементы структуры БД по заранее заданному шаблону. Читатели моего блога могут получить утилиту в подарок.

Отдельное спасибо Николаю Звереву за присланный отзыв о DB Meta Studio.

В сегодняшнем посте я хочу сделать краткий обзор инструмента ER Studio, который позиционируется как комплексное решение для моделирования, разработки архитектуры и создания проектов физических баз данных. Сразу оговорюсь, что существует довольно много редакций продукта, которые отличаются функциональным набором и, соответственно, ценой. В состав Delphi XE3 Architect входит Developer редакция продукта. Именно ее я и использовал. Подробнее о ценах на продукт я планирую рассказать на сайте компании DC Link (реселлер продуктов Embarcadero на территории Украины).

Получение модели

После запуска ER Studio список возможных действий не поражает особым разнообразием. И единственное, если не считать немногочисленных настроек, что можно сделать это создать новую модель. Стандартный диалог предлагает три варианта.

Создать новую модель “с чистого листа”, импортировать модель ERWin или выполнить т.н. обратную инженерию существующей БД (построить модель по существующей базе)  Естественно реверсинжайн, оказался для меня самым интересным вариантом. Последовательность из пяти интуитивно понятных диалогов позволяет настроить модель, выбрать ее нотацию, объекты, которые следует включать и определить другие настройки.

Читать далее

Продукты DevArt
Купить онлайн:



Читай русскоязычные Delphi блоги
Каталог блогов Blogdir.ru
Яндекс.Метрика