Программа для построения инфологической модели

В данной работе рассмотрено создание ER-диаграммы на примере детского магазина.

Ключевые слова

ER-ДИАГРАММА, БАЗЫ ДАННЫХ, ПРОЕКТИРОВАНИЕ

Текст научной работы

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

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

Комплекс задач этого этапа состоит в выявлении общих информационных объектов и связей между ними. Результаты инфологического проектирования могут быть выражены в виде инфологической или концептуальной модели, которая представляет структуру данных. Для построения концептуальной модели используется метод моделирования «Сущность — связь» или ER-диаграмма.

Основы проектирования баз данных. Концептуальная (инфологическая) модель.

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

Работа продавца-консультанта — это процесс, который можно разделить на следующие этапы:

• поиск нужного товара;
• формирование списка товаров;
• добавление информации о покупателях.

Информационные процессы этапов представлены в виде таблицы (Таблица 1.) .

1. поиск нужного товара

поиск товара на складе посредством побуквенного ввода названия товара, фирмы изготовителя или цене в поле поиска;

2. формирование списка товаров

вывод выбранных товаров в отдельную таблицу;

3. оформление документов клиента

сохранение информации в базу данных;

4. оформление продажи

выбор количества продаваемого товара;

После изучения предметной области и анализа структуры системы были определены объекты. Список сущностей и связей представлены в таблицах 2 и 3.

Поставщики ПОСТАВЛЮТ Товары

Товары СОСТОЯТ Типы

Товары НАХОДЯТСЯ Магазин

Магазин РАБОТАЮТ Сотрудники

Сотрудники ОФОРМЛЯЮТ Заказы

Заказы ДЕЛАЮТ Клиенты

Исходя из имеющихся данных, становится возможным построить ER-диаграмму, необходимую для дальнейшего проектирования информационной системы (рис.1).

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

Модель сущность связь, ER диаграмма

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

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

В Access можно создать схему данных, визуально представляющую логическую структуру базы данных. Определение отношений «один ко многим» в этой схеме должно соответствовать построенной модели данных. Появление схемы данных практически совпадает с графическим представлением информационно-логической модели. В таблицах 4 и 5 показаны структуры объектов «Товары» и «Сотрудники». Аналогично можно получить и другие таблицы базы данных.

Источник: novainfo.ru

Построение инфологической модели базы данных

Процесс построения диаграммы «сущность-связь» состоит из четырех основных этапов:

1. Определить список сущностей выбранной предметной области.
2. Определить список атрибутов сущностей.
3. Описать связи между сущностями (классы принадлежности, степени связей и атрибуты связей при необходимости).
4. Организовать данные в виде диаграммы «сущность-связь».

Пример построения инфологической модели

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

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

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

Завхозом, который связан с поставщиками продуктов, определяется перечень продуктов, необходимых для заказа, чтобы обеспечить работу столовой.

Шеф-поваром при составлении меню используется кулинарная книга, в которой размещены рецепты (рисунок 1) и таблицы с пищевой ценностью и химическим составом продуктов.

Таким образом, представляется возможным определить объекты, которые необходимы для определения атрибутов и сущностей проектируемой БД:

«Построение инфологической модели базы данных»
Готовые курсовые работы и рефераты
Решение учебных вопросов в 2 клика
Помощь в написании учебной работы

1. Блюда:
2. код (номер) блюда;
3. название;
4. вид (горячее, суп, закуска и т.п.);
5. рецепт приготовления;
6. выход (вес одной порции);
7. калорийность;
8. вес, название и основные вещества (витамины, углеводы, жиры, белки и др.) каждого продукта, который входит в блюдо;
9. стоимость приготовления одной порции (трудоемкость).
10. Поставщик продуктов:
11. код (номер) поставщика;
12. название поставщика с указанием его статуса (универсам, ферма, рынок и т.п.);
13. данные о поставщике (телефон, город, адрес);
14. название продукта, который поставляется;
15. цена на момент поставки и дата поставки.
16. Ежедневный расход блюд (потребление): дата, блюдо, число порций.
17. Меню на последующий день, в котором на каждую из трапез (завтрак, обед и ужин) предлагается несколько разных блюд.
18. Выбор каждым отдыхающим желаемых блюд из меню.

При анализе объектов можно выделить следующие:

• Стержни: ПОСТАВЩИКИ, ПРОДУКТЫ, ТРАПЕЗЫ и ВИДЫ_БЛЮД;
• Ассоциации: ВЫБОР (связь МЕНЮ и МЕСТА в столовой), МЕНЮ (связь ТРАПЕЗЫ и БЛЮД), ПОСТАВКИ (связь ПОСТАВЩИКОВ и ПРОДУКТОВ), СОСТАВ (связь БЛЮДА и ПРОДУКТОВ) и частный случай ассоциации – БЛЮДА, которые зависят от единственной стержневой сущности ВИДЫ_БЛЮД;
• Характеристика: РЕЦЕПТЫ (характеристика БЛЮД).

Рекомендации по построению инфологической модели базы данных

• Необходимо четко разграничить понятия запроса на данные и ведения данных (ввод, внесение изменений и удаление).
• Не забывать, что обычно база данных является информационной основой для нескольких (а не одного) приложений, часть из которых будет создана в будущем.
• При плохом проектировании базы данных не представляется возможным исправление такого проекта при помощи каких-либо приложений.

Источник: spravochnick.ru

Создание инфологической и даталогической модели данных

Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

Чаще всего концептуальная модель базы данных включает в себя:

описание информационных объектов, или понятий предметной области и связей между ними;

описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними [10].

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

В настоящее время условным общепринятым языком описания базы данных стал язык ER-модели. Для ER-модели существует алгоритм однозначного преобразования ее в реляционную модель данных, что позволило в дальнейшем разработать множество инструментальных компьютерных систем, поддерживающих процесс разработки информационных баз данных, основанных на технологии баз данных. И во всех этих системах существуют средства описания инфологической модели разрабатываемой БД с возможностью автоматической генерации той даталогической модели (СУБД-ориентированной), на которой будет реализовываться проект в дальнейшем. Такие автоматизированные инструментальные системы, основанные на методологии DEF1X, называются CASE-средствами проектирования информационных систем. А сама технология разработки – CASE-технологию создания и сопровождения информационных систем [10].

Первоначальное значение термина CASE (Computer Aided System Engineering), ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки информационных систем в целом. Под ним понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, которые в общем случае включают следующие этапы:

• анализ и формулировку требований предметной области;
• проектирование баз данных и прикладного программного обеспечения;
• генерацию кода для выбранной СУБД и языка приложений;
• тестирование;
• документирование;
• обеспечение требуемого качества работы информационной системы.

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

Рассмотрим некоторые аспекты информационного моделирования и его автоматизации с использованием программного CASE-средства ERWin v7.1.

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

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

Логический уровень означает прямое отображение фактов сущностей из реальной жизни. Например, печи, персонал, оборудование являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.).

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

ERWin предоставляет возможности создавать и управлять этими двумя различными уровнями представления диаграмм. Выбор между логическим и физическим уровнем отображения осуществляется через линейку инструментов или меню. Кроме этого, уровень детализации диаграммы информационной модели может изменяться проектировщиком. Например, могут отображаться только имена сущностей (таблиц), может быть включено/выключено отображение мощности связи и т.д.

Программа ERWin позволяет работать не со всей диаграммой, а с логически законченными группами сущностей (Subject Area), переключение между которыми производится выбором из раскрывающегося списка. Такая возможность позволяет проектировщику информационной модели удалить с экрана уже спроектированные блоки, чтобы они не загромождали диаграмму.

Все графические элементы модели ERWin могут редактироваться средствами, принятыми в Windows – группировка, копирование, удаление, перемещение, использование системного буфера обмена. С помощью удобных диалоговых окон имеется возможность использовать цветовое и шрифтовое выделение для различных компонентов диаграммы. Выделение может быть выполнено как для всей модели (например, все внешние ключи отображать красным цветом), так и для отдельного компонента (таблицы, атрибутов одной таблицы, одной связи и т.д.). Компоненты модели, представленные текстом (имена сущностей, атрибутов, текстовые комментарии) могут редактироваться непосредственно на экране. Использование цветового и шрифтового выделения на диаграмме информационной модели делает ее более наглядной и позволяет проектировщику обратить внимание пользователей диаграммы на ее отдельные элементы.

Процесс построения информационной модели в ERWin состоит из следующих этапов:

1. определение сущностей;
2. определение связей (зависимостей) между сущностями;
3. задание первичных и составных (альтернативных) ключей;
4. определение атрибутов сущностей;
5. приведение модели к требуемому уровню нормальной формы;
6. переход к физическому описанию модели: назначение соответствий имя сущности – имя таблицы, атрибут сущности – атрибут таблицы; задание ограничений предметной области;
7. генерация базы данных, т.е. формирование физической схемы для конкретной выбранной (целевой) СУБД.

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

• атрибуты, составляющие первичный ключ;
• неключевые атрибуты;
• тип сущности (независимая/зависимая).

Каждый атрибут сущности становится атрибутом соответствующего отношения. Для каждого атрибута задается конкретный допустимый с СУБД тип данных и обязательность или необязательность данного атрибута, т.е. допустимость или недопустимость NULL-значений для него. Первичный ключ сущности становится Primary Key соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

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

• тип связи (идентифицирующая или неидентифицирующая связь);
• родительская сущность;
• дочерняя (зависимая) сущность;
• мощность связи;
• допустимость пустых (null) значений.

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

Для определения связей ERWin выбирается тип связи, затем мышью указывается родительская и дочерняя сущность. Идентифицирующая связь изображается сплошной линией; неидентифицирующая – пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.

При определении связи происходит автоматическое перемещение (миграция) атрибутов первичного ключа родительской сущности в соответствующую область атрибутов дочерней сущности. Поэтому такие атрибуты не вводятся вручную. Атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами. ERWin позволяет ввести для них роли, т.е. новые имена, под которыми мигрирующие атрибуты будут представлены в дочерней сущности. На физическом уровне имя роли – это имя колонки внешнего ключа в дочерней таблице.

Мощность связи в соответствии с методологией IDEF1X представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Мощность связи записывается как 1:N. ERWin предоставляет 4 варианта для n, которые изображаются дополнительным символом у дочерней сущности: ноль, один или больше (по умолчанию); ноль или один; один или более; ровно N, где N – конкретное число. Допустимость пустых (null) значений в неидентифицирующих связей ERWin изображает пустым ромбиком на дуге связи со стороны родительской сущности.

Для каждой связи на логическом уровне могут быть заданы требования по обработке операций вставки, обновления и удаления (insert, update, delete) для родительской и дочерней сущности. Программа ERWin предоставляет следующие варианты обработки этих событий:

• отсутствие проверки;
• проверка допустимости;
• запрет операции;
• каскадное выполнение операции удаления/обновления (delete/update);
• установка пустого (null-значения) или заданного значения по умолчанию.

В соответствии с выбранным вариантом программа ERWin автоматически создает необходимые процедуры обработки этих событий (триггеры) на языке SQL целевой СУБД, которые могут быть переопределены после генерации схемы базы данных.

Разработанные модели ERWin сохраняются на диск в виде файла с расширением *.er1. Имеется возможность хранить модель в целевой СУБД. Для этого с помощью самой программы ERWin в целевой СУБД создается метабаза ERWin, в которой сохраняется информация о модели

Инфологическая модель предметной области, в данном случае характеризуется следующими особенностями:

• справочные данные попадают в базу данных по средствам ввода пользователем или автоматическим путем посредствам пакета Integration Services;
• расчет базируется на множестве параметров печи например температура внутри печи, толщины стенок, площадь поверхности и т.д.

Список сущностей, их назначение первичные и внешние ключи описаны в таблице 3.1.

Отношения между сущностями данной предметной области представляются в виде отношений: один-к-одному или один-ко-многим. Так же отношения между сущностями являются интуитивно понятными и не противоречат данной предметной области. Базовыми сущностями являются справочник типов материалов (tMatType), и справочник свойств стенки (tProperties) а так же Справочник предприятий и справочник типов печей.Эти сущности не содержат внешних ключей.

Таблица 3.1 — Список сущностей, их назначение первичные и внешние ключи

Источник: studfile.net