Разработка концептуальной модели сущность-связь в среде UML

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

Часто семантическое моделирование используется только на первой стадии проектирования базы данных. Концептуальная схема будущей БД строится на основе некоторой семантической модели, а затем вручную преобразуется к реляционной схеме.

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

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

Следует заметить, что многие начинающие проектировщики баз данных недооценивают важность семантического моделирования вручную. Зачастую это воспринимается как дополнительная и излишняя работа. Эта точка зрения является абсолютно неверной. Во-первых, построение мощной и наглядной концептуальной схемы БД позволяет более полно оценить специфику моделируемой предметной области и избежать возможных ошибок на стадии проектирования схемы реляционной БД. Во-вторых, на этапе семантического моделирования производится очень важная документация (хотя бы в виде вручную нарисованных диаграмм и комментариев к ним), которая может оказаться полезной не только при проектировании схемы реляционной БД, но и при эксплуатации, сопровождении и развитии уже заполненной БД.

Таблица 1- Сущность Товары

Таблица 2- Сущность Покупатели

Таблица 3- Сущность Поставщики

Вообще говоря, переход от диаграммного представления концептуальной схемы базы данных к ее реляционной схеме не зависит от разновидности используемых диаграмм. В частности, методика, разработанная для классических диаграмм «Сущность-Связь», практически всегда пригодна для диаграмм классов UML. Эта методика широко известна, и мы не будем повторять ее в этой статье. Тем не менее, кажется целесообразным привести несколько рекомендаций, которые тесно связаны со спецификой диаграмм классов.

Таким образом, в ИС «Альянс-Трейд» представлены следующие связи:

· Товары – Покупатели

·

м

· Поставщики – Товары

· Все связи – один ко многим.  

Логическая модель является основой базы данных, она должна отображать взаимосвязи между реляционными таблицами. Между реляционными таблицами могут быть следующие типы связей 1:1, 1:М и М:М. Наиболее распространенной связью является связь 1:М. Связь 1:1 встречается реже, так как данные между которыми существует такой тип связи в подавляющем большинстве случаев входят в состав одной реляционной таблицы. Связь М:М непосредственно не поддерживается в реляционными СУБД. Для реализации такой связи необходимо создавать дополнительную реляционную таблицу, которая будет играть роль связующей. Связующая таблица должна обязательно содержать первичные ключи таблиц, между которыми устанавливается связь.

В ходе анализа всех данных были выделены задачи, подлежащие автоматизации:

Ввод данных в таблицы;

· Создание пользовательских форм;

· Осуществление перехода между формами;

· Обеспечить поиск данных по запросам;

· Создание необходимых триггеров и хранимых процедур;

· Создание отчетов