Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #52, МАРТ 2005 г.

Информационное моделирование в ERwin

Лавров Владислав (l-vv@r66.ru)

Спецвыпуск: Хакер, номер #052, стр. 052-028-1


Создаем наглядную схему БД

До недавнего времени проектирование баз данных выполнялось с помощью методов, основанных исключительно на практическом опыте разработчиков. В первую очередь это объясняется отсутствием компьютерных средств автоматизации: запрограммировать процесс очень непросто.

Мир был обрадован появлением программы ERwin, которая позволяет визуально моделировать базу данных не задумываясь о таких вещах, как таблица, и представлять в наглядном виде общую картину будущей базы данных. А потом уже пару щелчков превратят все это в физическую базу любой из наиболее популярных СУБД.

Зачем это нужно?

Цель информационного, или, как его еще называют, семантического моделирования - создание концептуальной схемы БД. Эта схема (или просто модель) в упрощенном виде отражает наиболее важные для пользователей информационные объекты окружающего мира (предметной области) и связи между ними. Такая схема разрабатывается на ранних стадиях проектирования. После этого концептуальную схему импортируют в любую существующую СУБД, например, в Microsoft Access, Microsoft SQL Server, Oracle и др.

Зачем нужна концептуальная схема? Какую пользу она приносит проектировщикам?

Дело в том, что проект базы данных является тем фундаментом, на котором строится вся информационная система. Процесс проектирования всегда требует обсуждений с заказчиком, со специалистами в предметной области. Значит, требуется уметь представлять информацию о предметной области таким образом, чтобы была понятна всем и чтобы она была "читабельной" не только для специалистов по базам данных, но и для твоего корыстного начальника :).

Правда, известно, что большинство современных баз данных основываются на популярной реляционной модели, которую никто не запрещает использовать для обсуждения проекта. Эту модель не применяют по одной простой причине: она предназначена прежде всего для удобного представления структуры хранимых данных. А вот отображать смысл предметной области в ней проблематично, так как здесь все сведения об объектах реального мира представлены в виде равноправных таблиц. Смотрит-смотрит человек на набор связанных табличек – а определить, какой объект главный, а какой подчиненный, не может. Ранние модели данных (прежде всего иерархическая и сетевая) лучше отображали логику предметной области, поскольку они в явном виде определяли иерархические связи между объектами. А при использовании реляционной модели весь смысл реальной предметной области остается только в голове проектировщика.

Информационная модель - лучший выбор разработчика

Представь, что твой начальник поручил тебе сделать крупную базу данных по регистрации заказов на сборку компьютеров из комплектующих. Если сразу приниматься за внесение данных в какую-нибудь СУБД, например, в Microsoft Access, то тебе придется досконально изучить эту программу. Это факт, поскольку ты будешь долго и упорно переделывать свою систему под постоянно изменяющиеся требования заказчиков. А если вдруг все решится в пользу другой СУБД, например, Oracle, то у тебя появится море других проблем, и ты наверняка не порадуешь клиента готовым программным продуктом в установленные сроки.

Содержание  Вперед на стр. 052-028-2