Разработка модели информационной системы средствами CASE-технологиями (на примере ночного клуба)
Проектирования информационных систем и баз данных на основе анализа бизнес-процессов. Создание информационной системы по учету шоу-программ ночного клуба. Построение модели бизнес-процесса в нотации IDEF0 и модели базы данных с использованием ERWin.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 27.11.2020 |
| Размер файла | 1,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
САНКТ-ПЕТЕРБУРГСКИЙ ГУМАНИТАРНЫЙ УНИВЕРСИТЕТ ПРОФСОЮЗОВ
ЗАОЧНЫЙ ФАКУЛЬТЕТ
Кафедра ЭМПИ
КУРСОВАЯ РАБОТА
ДИСЦИПЛИНА Проектирование информационных систем
ТЕМА Разработка модели информационной системы средствами CASE-технологиями (на примере ночного клуба)
Выполнил(а) студент(ка):
303группы 3 курса
Петрухин Николай Вячеславович
Санкт-Петербург 2020г
Содержание
Введение
Постановка задачи разработки информационной системы
Задание на разработку информационной системы
Характеристика объекта управления
Структура ночного клуба
Функциональная модель бизнес-процесса
Моделирование в IDEF0
Расчет оценки функциональной модели
Моделирование в DFD
Моделирование в IDEF3
Модели данных информационной системы
Концептуальная и логическая модель
Концептуальная модель данных
Логическая модель данных
Выбор и обоснование СУБД
Физическая модель данных в 4НФ из ERWin
Представления в базе данных из ERWin
Реализация информационной системы в СУБД
Программа реализации базы данных из ERWin
Макеты форм Создадим необходимые формы рис.16-18
Макеты отчетов
Главная кнопочная форма
Заключение
Список литературы
Введение
Данная курсовая работа выполняется по дисциплине «Проектирование информационных систем». Данная дисциплина предполагает освоение студентами методов анализа бизнес-процессов, необходимых для проектирования информационных систем (ИС), проектирование баз данных на основе анализа бизнес процессов. Получение практических навыков работы с CASE-технологиями BPWin и ERWin.
Тема курсовой работы ««Разработка модели информационной системы средствами CASE-технологий (на примере ночного клуба)».Цель курсовой работы - создание информационной системы по учету шоу-программ ночного клуба.
Для этого следует решить следующие задачи:
- изучить предметную область;
- построить модель бизнес-процесса в нотации IDEF0;
- уточнить модель бизнес-процесса с использованием DFD и IDEF3;
- построить модель базы данных с использованием ERWin;
- реализовать БД в СУБД Access.
Для выполнения курсовой работы использованы CASE-средства BPWin и ERWin.
Постановка задачи разработки информационной системы
Задание на разработку информационной системы
база данные информационный модель
Заведение - Ночной клуб.
Требуется спроектировать ИС, которая позволит автоматизировать процесс назначения работников для проведения шоу.
Информационная система должна решать следующие задачи:
1. Ведение базы данных о (далее согласно варианту задания):
* Пополнение.
* Редактирование
2. Поиск информации о персонале:
* Выборкой.
* С вычислениями.
* С подведением итогов.
3. Оформление документов по результатам поиска.
Информационная система должна содержать:
1. Реляционную базу данных.
2. Совокупность представлений и запросов.
3. Формы для ведения базы данных.
4. Отчеты по результатам запросов.
Характеристика объекта управления
Ночной клуб проводит вечеринки, эксклюзивные концерты, шоу… Обычно 2-3 событий в год, и не стоит при этом ориентироваться только на приглашение ди-джеев - к сожалению, эта профессия уже перестает быть модной.
Клуб оказывает следующие услуги:
· танцевальные программы;
· тематические вечеринки (на Новый Год и другие праздники);
· европейская кухня (горячие блюда, закуски, коктейли, соки, алкогольные напитки);
· аренда столиков;
· vip-зона;
· бар с алкогольными и безалкогольными напитками;
· банкеты, свадьбы и корпоративы.
Целевая аудитория клуба -- молодые люди в возрасте от 18 до 40 лет. Так как клуб будет располагаться в центре города, то посетителями будут офисные сотрудники, а также студенты различных ВУЗов. В результате ценовую политику клуба и формат заведения определяется исходя из этих двух факторов.
Основные услуги: танцевальные программы, тематические вечеринки, свадьбы, корпоративы и банкеты. Средний чек будет составлять - 700 рублей. Это не элитное заведение, в основном рассчитано на людей с низким и средним уровнем дохода. Предполагается получать доход от большой посещаемости.
Направление музыки - Disсo.
Вместимость - 180 человек.
Цены в клубе -- средние. Также присутствует плата за вход.
Стоимость билета - в пятницу, субботу и воскресенье по 200 рублей.
Структура ночного клуба
Услуги, которые предоставляются в заведении, целиком и полностью зависят от концепции и аудитории. Важно учитывать возрастное ограничение. Программу надо регулярно освежать, не стоять на месте.
Поэтому ночной клуб имеет арт-директора и промоутер -- для организации работы и продвижения клуба.
Ночному клубу требуется следующий персонал:
· Управляющий
· Администратор (3 человека)
· Бармен (4 человека)
· Официант (10 человек)
· Шеф-повар
· Повар (4 человек)
· Уборщица (4 человека)
· Мойщик посуды (3 человека)
· Специалист по закупкам
· Диджей
· Ведущий (2 человека)
Общая площадь заведения 510 м2:
· танцевальный зал - 200 м2;
· столики и vip-кабинки - 110 м2;
· кухня - 50 м2;
· холл, раздевалка, туалеты - 80 м2;
· складские и подсобные помещения - 70 м2.
Помещения оборудуются в соответствии с нормами противопожарной безопасности. Предполагается одновременная работа 2 баров.
Ночной клуб имеет следующее оборудование:
· Музыкальное оборудование
· Компьютеры
· Принтеры
· Световое оборудование
· Кухонное и холодильное оборудование
· Посуда и прочий инвентарь
· Кассовые терминалы
Функциональная модель бизнес-процесса
Моделирование в IDEF0
IDEF0 или IDEFШ (определение интеграции для моделирования функций) - это метод, предназначенный для моделирования решений, действий и действий организации или системы. IDEFШ был создан на основе хорошо зарекомендовавшего себя графического языка - структурированного анализа и методики проектирования (SADT).
ВВС США поручили разработчикам SADT разработать метод моделирования для анализа и представления функциональной схемы системы. Эффективные модели IDEFШ помогают организовать анализ системы и способствуют хорошей коммуникации между аналитиком и клиентом. IDEFШ полезен для определения объема анализа, особенно для функционального анализа. Как инструмент коммуникации, IDEFШ улучшает участие экспертов в предметной области и консенсуса в принятии решений с помощью упрощенных графических устройств. Как инструмент анализа, IDEFШ помогает моделисту определить, какие функции выполняются, что необходимо для выполнения этих функций, что текущая система делает хорошо или плохо. Таким образом, модели IDEFШ часто создаются как одна из первых задач в процессе разработки системы.
В декабре 1993 года Лаборатория системной информатики Национального института стандартов и технологий (NIST) 2 выпустила IDEFШ в качестве стандарта для функций моделирования в публикации FIPS 183.
IDEF0 (Integration DEFinition for Function) - это метод создания диаграммы процесса обработки или бизнес-процесса. В IDEF0 прямоугольник представляет шаг процесса. Этот шаг процесса имеет один или несколько входов и выходов, которые показаны стрелками.
Вывод шага процесса создается путем обработки ввода. Операция шага процесса здесь не обсуждается, а только функция, которую выполняет этот шаг. Такой подход к реальности называется функциональной моделью.
Сторона, с которой стрелка связана с прямоугольником, имеет значение в IDEF0. Левая сторона для входа и правая сторона для выхода. Верх для контроля шага процесса. Нижняя часть предназначена для входящих деталей редактирования (механизм функции) или для исходящих ссылок на другие шаги процесса, которые содержат детали редактирования.
Каждое действие описывается меткой на основе глагола, помещенной в поле. Входные данные показаны в виде стрелок, входящих в левую часть поля активности, а выходные - в виде выходных стрелок в правой части окна. Элементы управления отображаются в виде стрелок, входящих в верхнюю часть окна, а механизмы отображаются в виде стрелок, входящих в нижнюю часть окна. Входы, элементы управления, выходы и механизмы (ICOM) называются концепциями.
Стрелка: направленная линия, состоящая из одного или нескольких сегментов стрелки, которая моделирует открытый канал или канал, по которому передаются данные или объекты из источника (без стрелки) для использования (со стрелкой). Существует 4 класса стрелок: Стрелка ввода, Стрелка вывода, Стрелка управления и Стрелка механизма (включая Стрелку вызова).
Поле: прямоугольник, содержащий имя и номер, используемый для представления функции.
Контекст: Непосредственная среда, в которой работает функция (или набор функций на диаграмме).
Декомпозиция: разбиение моделируемой функции на составляющие функции.
Вилка: Узел, на котором сегмент стрелки IDEF0 (переходящий от источника к использованию) делится на два или более сегмента стрелки. Может обозначать разделение значений.
Функция: действие, процесс или преобразование (смоделированное блоком IDEF0), идентифицируемое глаголом или фразой глагола, которая описывает, что должно быть выполнено.
Регистрация: Соединение, при которой стрелка IDEF0 сегмент (идущий от источника к использованию) сливается с одним или несколькими другими сегментами стрелок, чтобы сформировать один сегмент стрелки. Может обозначать связывание значений сегментов стрелок
Узел: ящик, из которого происходят дочерние ящики; родительская коробка.
Если блок-схема функционального потока используется для отображения функционального потока продукта, IDEF0 используется для отображения потока данных, управления системой и функционального потока процессов жизненного цикла. IDEF0 способен графически представлять широкий спектр деловых, производственных и других типов операций предприятия на любом уровне детализации. Это обеспечивает строгое и точное описание, и способствует последовательности использования и интерпретации. Это хорошо проверено и доказано в течение многих лет использования правительством и частной промышленностью. Он может быть создан различными инструментами компьютерной графики. Многочисленные коммерческие продукты специально поддерживают разработку и анализ диаграмм и моделей IDEF0.
Процесс IDEF0 начинается с идентификации основной функции, подлежащей разложению. Эта функция указана в «Контекстной диаграмме верхнего уровня», которая определяет область конкретного анализа IDEF0. Из этой диаграммы генерируются диаграммы нижнего уровня.
Составим контекстную диаграмму в BPWin рис.1
Рисунок 1 Контекстная диаграмм
Report for Diagram: A-0, Ночной клуб
Activity Name: Ночной клуб
Управление:
Link Name: Правила клуба
Link Name: Шаблоны шоу
Link Name: Правила ведения БУ
Link Name: Должностные инструкции
Исполнительные механизмы:
Link Name: Арт-директор
Link Name: Персонал
Link Name: Бухгалтер
Вход:
Link Name: Клиенты клуба
Link Name: Конъюнктура
Link Name: Оборудование и помещения
Выход:
Link Name: Заказ продуктов
Link Name: Отчет
Link Name: Мусор
Link Name: Прибыль
Выполним декомпозицию контекстной диаграммы, рис.2:
Рисунок 2 Декомпозиция контекстной диаграммы
Report for Diagram: A0, Ночной клуб
Activity Name: Планирование шоу-программы
Activity Name: Подготовка шоу-программы
Activity Name: Проведение шоу
Activity Name: Составление отчетности
Link Name: Правила клуба
Link Name: Персонал
Link Name: Заказ продуктов
Link Name: Клиенты клуба
Link Name: Конъюнктура
Link Name: Шаблоны шоу
Link Name: Арт-директор
Link Name: Шоу-программа
Link Name: Оборудование и помещения
Link Name: Отчет
Link Name: Бухгалтер
Link Name: Выручка
Link Name: Зал
Link Name: Правила ведения БУ
Link Name: Мусор
Link Name: Прибыль
Link Name: Должностные инструкции
Выполним декомпозицию бизнес-процесса «Планирование шоу-программы», рис.3. Именно этот бизнес-процесс будет автоматизироваться.
Рисунок 3 Декомпозиция блока А1
Report for Diagram: A1, Планирование шоу-программы
Activity Name: Маркетинговый анализ
Activity Name: Подбор шоу
Activity Name: Подбор персонала
Activity Name: Менеджмент
Link Name: Конъюнктура
Link Name: Шаблоны шоу
Link Name: Арт-директор
Link Name: Шоу-программа
Link Name: Спрос
Link Name: Список мероприятий
Link Name: Список работников
Link Name: Должностные инструкции
Построим дерево декомпозиции в BPWin, рис.4
Рисунок 4 Дерево декомпозиции
Расчет оценки функциональной модели
Выполним расчет стоимости эксплуатации системы в BPWin [2], рис.5
Рисунок 5 Назначение стоимости работ
Получим
Activity Number: 1
Activity Name: Планирование шоу-программы
Activity Cost ($ U.S.): 5,00
Cost Center: Работа 1
Cost Center Cost ($ U.S.): 4,00
Cost Center: Работа 2
Cost Center Cost ($ U.S.): 1,00
Activity Number: 11
Activity Name: Маркетинговый анализ
Activity Cost ($ U.S.): 2,00
Cost Center: Работа 1
Cost Center Cost ($ U.S.): 2,00
Activity Number: 12
Activity Name: Подбор шоу
Activity Cost ($ U.S.): 1,00
Cost Center: Работа 1
Cost Center Cost ($ U.S.): 1,00
Activity Number: 13
Activity Name: Подбор персонала
Activity Cost ($ U.S.): 1,00
Cost Center: Работа 1
Cost Center Cost ($ U.S.): 1,00
Activity Number: 14
Activity Name: Менеджмент
Activity Cost ($ U.S.): 1,00
Cost Center: Работа 2
Cost Center Cost ($ U.S.): 1,00
Моделирование в DFD
Диаграмма потоков данных (DataFlow диаграммы), метод использования, предоставление и модификацию данных в программе. Она также может быть использована для контроля поток данных из процесса или активности воспроизведения (г. е. используя данные и изменения в создании предложения в торговой компании). Диаграмма потока данных не имеет потока управления, нет правил принятия решений и циклов. Конкретные операции над данными могут быть представлены блок-схемой программы.
Диаграмма потока данных различает четыре типа элементов со следующей семантикой.
Хранилище данных: представлено двумя параллельными линиями, между которыми находится имя хранилища (может быть смоделированов UML как узел буфера ).
Поток данных: представлен стрелкой с именем. Если функция имеет доступ для чтения и записи в память данных, это может быть представлено либо двумя отдельными стрелками, либо двойной стрелкой.
Функция (или процесс ): представлена ??кругом с именами (сравнимым с действием в UML ).
Интерфейс для среды: представлен прямоугольником, который содержит имя интерфейса (внешний партнер). Интерфейсы, через которые поток данных поступает в систему, называются источниками данных. Интерфейсы, через которые поток данных выходит из системы, называются приемниками данных.
Существуют разные обозначения для отображения диаграмм потоков данных. Вышеуказанная запись была описана Томом ДеМарко в 1979 году в рамках Структурного анализа.
Для каждого потока данных, по крайней мере, одна из конечных точек (источник и / или цель) должна быть процессом. Процесс может быть уточнен в следующей диаграмме потока данных, которая разделяет этот процесс на подпроцессы.
Диаграмма потока данных является одним из инструментов моделирования структурного анализа. При использовании UML диаграмма активности обычно играет роль диаграммы потока данных. Особой формой плана потока данных является план потока данных, ориентированный на работу, который также называется «кто / что». Мероприятия назначаются отдельным участникам в вертикальных дорожках на каждого участника.
Кроме того, диаграммы потоков данных могут быть интерпретированы как инвертированные сети Петри, поскольку места в таких сетях соответствуют семантике хранения данных. Точно так же семантика переходов из сетей Петри и потоков данных и функций из диаграмм потоков данных может рассматриваться как эквивалентная.
Имена сущностей должны быть понятными без дальнейших комментариев. DFD - это система, созданная аналитиками на основе интервью с пользователями системы. Он определяется для разработчиков системы, с одной стороны, для подрядчика проекта, с другой, поэтому имена объектов должны быть адаптированы для модельного домена, а также для пользователей или профессионалов-любителей. Названия объектов должны быть общими (независимыми, например, конкретные лица, выполняющие деятельность), но должны четко указывать объект. Процессы должны быть пронумерованы для более простого отображения и направления к конкретным процессам. Нумерация случайная, однако необходимо поддерживать согласованность на всех уровнях DFD (см. Иерархия DFD). DFD должен быть четким, так как максимальное количество процессов в одном DFD рекомендуется от 6 до 9, минимум 3 процесса в одном DFD. Исключением является так называемая контекстная диаграмма, где единственный процесс символизирует модель системы и все терминаторы, с которыми система взаимодействует.
Чтобы сделать DFD более прозрачным (т.е. не слишком много процессов), можно создавать многоуровневые DFD. DFD, которые находятся на более высоком уровне, являются менее подробными (агрегируйте более подробные DFD на более низких уровнях). Контекстный DFD является самым высоким в иерархии. За так называемым нулевым уровнем следует DFD 0, начиная с нумерации процесса (например, процесс 1, процесс 2). На следующем, так называемом первом уровне - DFD 1 - нумерация продолжается. Например, процесс 1 разделен на первые три уровня DFD, которые пронумерованы как 1.1, 1.2 и 1.3. Аналогично, процессы на втором уровне (DFD 2) нумеруются, например, 1.1.1, 1.1.2, 1.1.3 и 1.1.4. Количество уровней зависит от размера модельной системы. Процессы DFD 0 могут не иметь одинакового количества уровней разложения. DFD 0 содержит наиболее важные (агрегированные) системные функции. Самый нижний уровень должен включать процессы, которые позволяют создать спецификацию процесса (Process Specification) примерно для одной страницы формата A4. Если мини-спецификация должна быть длиннее, целесообразно создать дополнительный уровень для процесса, где она будет разложена на несколько процессов. Для четкого обзора всей иерархии DFD может быть создана вертикальная (поперечная) диаграмма. Склад отображается на самом высоком уровне, где он впервые используется, а также на каждом более низком уровне.
Построение модели бизнес-процесса в DFD для работы «Планирование шоу-программы», рис.6
Рисунок 6 DFD-диаграмма
Report for Diagram: A0, План Рисунок 1 - Декомпозиция блока А1
Планирование шоу-программ:
Activity Name: Анализ спроса и предложения
Activity Name: Выбор продукта
Activity Name: Составление плана
Link Name: Конюнктура
Link Name: Шоу-программа
Link Name: Спрос
Data Store Name: Конкуренты
Data Store Name: Продукты
Моделирование в IDEF3
IDEF3 или интегрированное определение DEF для процесса Описание Capture Method - это метод моделирования бизнес-процессов, дополняющий IDEF0. Метод IDEF3 - это метод захвата описания потока процесса на основе сценария, предназначенный для сбора информации о том, как работает конкретная система. Метод IDEF3 предоставляет режимы для представления переходов: Описания потоков процессов для захвата отношений между действиями в контексте конкретного сценария и Переход состояния объекта для захвата описания допустимых состояний и условий.
Этот метод является частью семейства языков IDEF в области разработки систем и программного обеспечения.
Схемы процессов, как правило, являются наиболее знакомым и широко используемым компонентом метода IDEF3. Эти схемы обеспечивают механизм визуализации описаний сценария, ориентированного на процесс. Графические элементы, составляющие схемы процесса, включают в себя блоки «Единица поведения» (UOB), ссылки на приоритет, соединения, ссылки и примечания. Строительные блоки здесь следующие. Единицы Поведения (UOB) коробки
Ссылки: Ссылки являются связующим звеном, соединяющим блоки UOB для формирования представлений динамических процессов.
Простые прецедентные ссылки: прецедентные ссылки выражают временные отношения приоритетов между экземплярами одного UOB и экземплярами другого.
Графики активации: Графики активации используются для представления активаций.
Пунктирные ссылки: пунктирные ссылки не имеют предопределенной семантики.
Номера ссылок: все ссылки имеют подробные и уникальные номера ссылок.
Семантика активации для схем неразветвленных процессов.
Пересечения: Пересечения в IDEF3 предоставляют механизм для определения логики ветвления процесса.
Разложения UOB: разработки собирают и структурируют подробные знания о процессах.
Схема нумерации справочных объектов UOB: номер блока UOB назначается каждому блоку UOB в описании процесса IDEF3.
Частичное описание: UOB-блоки объединены ссылками. Поскольку захват описания находится в центре внимания IDEF3, можно представить UOB без ссылок на другие части схемы IDEF3.
Ссылки: ссылки улучшают понимание, дают дополнительное значение и упрощают построение (то есть минимизируют беспорядок) как схем процессов, так и схем объектов.
Понятие сценария или истории используется в качестве основной организационной структуры для описаний процессов IDEF3. Сценарий можно рассматривать как повторяющуюся ситуацию, набор ситуаций, которые описывают типичный класс проблем, решаемых организацией или системой, или настройку, в которой происходит процесс. Сценарии устанавливают фокус и граничные условия описания. Использование сценариев таким образом использует тенденцию людей описывать то, что они знают, с точки зрения упорядоченной последовательности действий в контексте данного сценария или ситуации. Сценарии также предоставляют удобный инструмент для организации коллекций процессно-ориентированных знаний.
Описания IDEF3 разрабатываются с двух разных точек зрения: процессно-ориентированного и объектно-ориентированного. Поскольку эти подходы не являются взаимоисключающими, IDEF3 позволяет создавать перекрестные ссылки между ними для представления сложных описаний процессов
Построение модели бизнес-процесса в IDEF3 для работы «Подбор персонала», рис.7
Рисунок 7 IDEF3-диаграмма
Report for Diagram: A13.1, Подбор персонала
Activity Name: Выбрать шоу
Activity Name: Найти актеров
Activity Name: Найти обслуживающий персонал
Activity Name: Назначить администратора
Activity Name: Составить список
Link Name: Список мероприятий
Link Name: Список работников
Junction Name: Unnamed
Junction Name: Unnamed
Модели данных информационной системы
В данной работе используется приложение Erwin. Erwin Data Modeler (стилизованный под erwin, но ранее как ERwin ) - это компьютерная программа для моделирования данных. Изначально разработанный компанией Logic Works, Erwin был приобретен рядом компаний, прежде чем был выделен частной инвестиционной фирмой Parallax Capital Partners, которая приобрела и объединила его в качестве отдельной организации, erwin, Inc., управляемой генеральным директором Адамом. Famularo.
Движок программного обеспечения основан на методе IDEF1X, хотя теперь он также поддерживает диаграммы, отображаемые с альтернативной инженерной нотацией для информационных технологий, а также нотацию для размерного моделирования.
Существует традиция построения моделей ER / data на двух или трех уровнях абстракции. Обратите внимание, что концептуально-логико-физическая иерархия, приведенная ниже, используется в других видах спецификаций и отличается от подхода трех схем к разработке программного обеспечения.
На первом этапе проектирования информационной системы эти модели используются во время анализа требований для описания потребностей в информации или типа информации, которая должна храниться в базе данных. Моделирования данных методика может быть использована для описания любой онтологии (т.е. обзора и классификации используемых терминов и их отношений) для определенной области интересов. В случае проектирования информационной системы, основанной на базе данных, концептуальная модель данных на более позднем этапе (обычно называемая логическим дизайном) сопоставляется с логической моделью данных, такой как реляционная модель ; это в свою очередь отображается на физическую модель во время физического проектирования. Обратите внимание, что иногда обе эти фазы называют «физическим дизайном».
Концептуальная и логическая модель
IDEF1X является языком моделирования в стандарте автоматизированного производства и относится к группе языков IDEF.
Стандарт определяет обозначения для диаграммы ER и дополнительную информацию в документации ERM. Следующие соглашения применяются к диаграмме.
Объекты отображаются в виде скругленного прямоугольника, если они зависят от существования отношения, в противном случае в нормальном прямоугольнике. Имя (или номер) помещается поверх него.
Имена атрибутов записаны в прямоугольнике объекта. Атрибуты, принадлежащие первичному ключу, находятся выше, все остальные - под дефисом.
Отношения знают направление (например, также в UML ), способ выражения: они переходят от родительского объекта к дочернему объекту. Дочерний конец отношений отмечен маленьким черным кружком. Кроме того, кардинальность отношения отображается типом строки, концом и комментарием.
В дополнение к кружку в дочернем конце линии отношений, существует количество дочерних объектов:
Ничего Ноль, одно или любое число
P Один на любой номер
Z Ноль или один
N Именно п
n - m между n и m
Мощность родительской стороны отношений может быть определена только как необходимость. У необязательного отношения есть ромб в конце строки родительской стороны, у императивного отношения - нормальный конец строки.
Это означает, что в IDEF1X запрещены отношения n: m, которые существуют среди прочего в нотации Чена. При моделировании отношение n: m должно быть разбито на два отношения 1: n.
Другая особенность по сравнению с другими обозначениями - это явное представление атрибутов внешнего ключа, хотя они являются избыточными с точки зрения моделирования. В дополнение к именам добавляются другие метки
Чен нотация представляет собой графическое обозначение модели сущность-связь. Он назван в честь ученого Питера Чена, который представил его вместе с моделью отношений сущностей в 1976 году для представления моделей данных.
Концептуальная модель данных
Это модель ER самого высокого уровня, поскольку она содержит наименьшую детализацию, но устанавливает общий объем того, что должно быть включено в набор моделей. Концептуальная модель ER обычно определяет основные эталонные объекты данных, которые обычно используются организацией. Разработка концептуальной модели ER в масштабе всего предприятия полезна для поддержки документирования архитектуры данных для организации.
Концептуальная модель ER может использоваться в качестве основы для одной или нескольких логических моделей данных. Целью концептуальной модели ER является установление общности структурных метаданных для объектов основных данных между набором логических моделей ER. Концептуальная модель данных может использоваться для формирования отношений общности между моделями ER в качестве основы для интеграции модели данных.
В методологии ER разработка модели начинается с построения концептуальной модели рис.8
Рисунок 8 Концептуальная модель
Сущность - это вещь, которая существует физически или логически. Объектом может быть физический объект, такой как дом или автомобиль (они существуют физически), событие, такое как продажа дома или автосервис, или понятие, такое как транзакция или заказ клиента (они существуют логически), как понятие ).
Хотя термин сущность является наиболее часто используемым, следуя Чену, мы должны действительно различать сущность и тип сущности. Тип объекта - это категория. Строго говоря, сущность является экземпляром данного типа сущности. Обычно существует много экземпляров типа объекта. Поскольку термин «тип объекта» несколько громоздок, большинство людей склонны использовать его как синоним этого термина.
Сущности можно рассматривать как существительные. Примеры: компьютер, сотрудник, песня, математическая теорема и т. д.
Отношения фиксируют, как сущности связаны друг с другом. Отношения можно рассматривать как глаголы, связывающие два или более существительных. Примеры: имеет отношение между компанией и компьютером, контролирует отношения между работником и департаментом, преформами отношением между художником и песней, доказывает связь между математиком и гипотезой и т.д.
Логическая модель данных
Логическая модель ER не требует концептуальной модели ER, особенно если область применения логической модели ER включает только разработку отдельной информационной системы. Логическая модель ER содержит больше деталей, чем концептуальная модель ER. В дополнение к объектам основных данных теперь определяются объекты операционных и транзакционных данных. Детали каждого объекта данных разработаны, и отношения между этими объектами данных установлены. Однако логическая модель ER разрабатывается независимо от конкретной системы управления базами данных, в которую она может быть внедрена.
Заменяем сущности на таблицы, получаем логическую модель, рис.9
Рисунок 9 Логическая модель
Выбор и обоснование СУБД
Microsoft Access - это программное обеспечение для баз данных, которое предоставляет шаблоны, которые помогут вам начать работу, и новые веб-базы данных, которые облегчают отслеживание, создание отчетов и обмен данными с другими.
Microsoft Access хранит данные в своем собственном формате на основе ядра базы данных Access Jet. Он также может импортировать или связывать напрямую с данными, хранящимися в других приложениях и базах данных.
Разработчики программного обеспечения, архитекторы данных и опытные пользователи могут использовать Microsoft Access для разработки прикладного программного обеспечения. Как и другие приложения Microsoft Office, Access поддерживается Visual Basic for Applications (VBA), языком программирования на основе объектов, который может ссылаться на различные объекты, включая устаревшие DAO (объекты доступа к данным), объекты данных ActiveX и многие другие компоненты ActiveX, Визуальные объекты, используемые в формах и отчетах, предоставляют свои методы и свойства в среде программирования VBA, а модули кода VBA могут объявлять и вызывать операции операционной системы Windows.
Пользователи могут создавать таблицы, запросы, формы и отчеты, а также связывать их вместе с макросами. Опытные пользователи могут использовать VBA для написания многофункциональных решений с расширенными возможностями манипулирования данными и контроля пользователей. Access также имеет функции создания отчетов, которые могут работать с любым источником данных, к которому может получить доступ Access.
Первоначальная концепция доступа была для конечных пользователей, чтобы иметь возможность доступа к данным из любого источника. Другие функции включают в себя: импорт и экспорт данных во многие форматы, включая Excel, Outlook, ASCII, dBase, Paradox FoxPro, SQL Server и Oracle. Он также имеет возможность связывать данные с существующим местоположением и использовать их для просмотра, запросов, редактирования и создания отчетов. Это позволяет изменять существующие данные, гарантируя, что Access использует самые последние данные. Он может выполнять гетерогенные объединения между наборами данных, хранящимися на разных платформах. Доступ часто используют люди, загружающие данные из баз данных уровня предприятия для локального манипулирования, анализа и составления отчетов.
Существует также формат базы данных Jet (MDB или ACCDB в Access 2007), который может содержать приложение и данные в одном файле. Это делает очень удобным распространение всего приложения другому пользователю, который может запускать его в автономных средах.
Одним из преимуществ Access с точки зрения программиста является его относительная совместимость с SQL ( язык структурированных запросов ) - запросы можно просматривать графически или редактировать как операторы SQL, а операторы SQL можно использовать непосредственно в макросах и модулях VBA для манипулирования таблицами Access. Пользователи могут смешивать и использовать как VBA, так и «Макросы» для программирования форм и логики и предлагают объектно-ориентированные возможности. VBA также может быть включен в запросы.
Microsoft Access предлагает параметризованные запросы. На эти запросы и таблицы доступа можно ссылаться из других программ, таких как VB6 и.NET, через DAO или ADO. Из Microsoft Access VBA может ссылаться на параметризованные хранимые процедуры через ADO. Microsoft Access проще в использовании, чем другие СУБД -
во-первых, он импортирует данные из других источников без ошибок по сравнению с другими приложениями;
во-вторых, Access имеет очень удобную емкость хранения, которая может выдерживать огромное количество данных, а также может использоваться многими пользователями в сети, получающей доступ к приложению Access.
Физическая модель данных в 4НФ из ERWin
Физическая модель данных.Одна или более физических моделей ER могут быть разработаны из каждой логической модели ER.
Физическая модель ER обычно разрабатывается для создания экземпляра в виде базы данных. Следовательно, каждая физическая модель ER должна содержать достаточно деталей для создания базы данных, и каждая физическая модель ER зависит от технологии, поскольку каждая система управления базой данных несколько отличается.
Физическая модель обычно конкретизируется в структурном метаданных системы управления базами данных как объекты реляционных баз данных, таких как таблицы базы данных, индексов базы данных, такие как уникальные ключевые индексы и ограничения базы данных, такие как ограничение внешнего ключа или общностью ограничения. Модель ER также обычно используется для разработки модификаций объектов реляционной базы данных и для поддержки структурных метаданных базы данных.
Теперь определяем поля для конкретного СУБД, получаем физическую модель, рис.10
Рисунок 10 Физическая модель
Представления в базе данных из ERWin
Создадим Views, рис.11-12
Рисунок 11 Представления для БД
Рисунок 12 Дерево Views
Реализация информационной системы в СУБД
Программа реализации базы данных из ERWin
Создадим пустую БД в Access. Подключим БД и используем инструмент прямого инжиниринга. Генерируем в ERWin программу создания базы данных в выбранной СУБД рис.13.
Рисунок 13 Создание БД на основе модели
И формирум в ERWin представления для получения необходимой информации.
В результате получаем базу данных, рис.14.
Рисунок 15 Таблицы, связи между таблицами и виды
Макеты форм Создадим необходимые формы рис.16-18
Рисунок 16 Форма «Персонал»
Рисунок 17 Форма «Шоу-программы»
Рисунок 18 Форма «Шоу-программы» в работе
Макеты отчетов
Создадим отчет, рис.19-20.
Рисунок 19 Отчет в конструкторе
Рисунок 20 Отчет в работе
Главная кнопочная форма
Создадим главную кнопочную форму, рис.21-22.
Рисунок 21 Главная кнопочная форма
Рисунок 22 Главная кнопочная форма в работе
Заключение
В настоящей курсовой работе спроектирована база данных для учета шоу-программ в ночном клубе. В качестве среды разработки была использована BPWin, ERWin и СУБД Microsoft Office Access 2007.
В первой части выполнена постановка задачи на проектирование информационной системы для ночного клуба. Дано описание заведения и его структуры. Во второй части разработана модель бизнес-процессов. Для создания модели использованы методологии IDEF0, DFD и IDEF3.
В третьей части выполнено проектирование базы данных на основе ER-методологии. Построена логическая и физическая модель базы данных.
В четвертой части, на основе модели базы данных, создана база данных для СУБД Access. Созданы формы, отчеты и главная форма. Таким образом, все задачи курсовой работы решены.
Файлы с приложениями в BPWin, в ERWin, в СУБД Access и отчетом по курсовой работе, составленным в текстовом редакторе Word, прилагаются.
Список литературы
1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: учеб. М., 2011.
2. Маклаков С. В. BPwin и ERwin. CASE-средства разработки информационных систем. М., 2000.
3. Маклаков С. В. Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1).М., 2003.
4. Проектирование экономических информационных систем: учеб. / под ред. Ю. Ф.Тельнова. М., 2011.
5. Хлебников А.А. Информационные технологии: учебник для студ. вузов/ А. А. Хлебников. -М.: КноРус, 2016.-465 с.
6. Макарова Н. В. Информатика: учебник для вузов/ Н. В. Макарова, В. Б.
7. Путькина Л. В. Информатика и математика для гуманитарных вузов: учебное пособие/ Л.В. Путькина, Т. Г. Пискунова, Т. Б. Антипова; СПб Гуманит. ун-т профсоюзов. - СПб.: СПбГУП, 2014.-240 с.:я-ил.. -(Библиотека гуманитарного Университета; Вып. 53).
8. http://www.intuit.ru/ - Национальный открытый университет
9. http://ecsocman.hse.ru/ - Федеральный образовательный портал Экономика, Социология, Менеджмент
Размещено на Allbest.ru
...Подобные документы
Описание предметной области разрабатываемой базы данных для теннисного клуба. Обоснование выбора CASE-средства Erwin 8 и MS Access для проектирования базы данных. Построение инфологической модели и логической структуры базы данных, разработка интерфейса.
курсовая работа [3,8 M], добавлен 02.02.2014Содержательное описание предметной области. Структурный анализ бизнес-процесса на основе IDEF0-модели. Построение информационно-логической модели данных. Структурная схема на основе IDEF0. Даталогическая модель данных. Реализация информационной системы.
курсовая работа [849,7 K], добавлен 10.07.2014Анализ деятельности гостиницы. Структурный анализ бизнес-процесса на основе IDEF0-модели. Особенности построения инфологической и даталогической модели данных. Аспекты проектирования базы данных гостиницы с использованием программного языка Delphi.
курсовая работа [1,6 M], добавлен 15.02.2014Проектирование модели информационной системы "Гостиница" в стандарте IDEF0. Разработка диаграммы потоков данных (Data Flow Diagramming), предназначенной для описания документооборота и обработки информации. Создание диаграммы декомпозиции в нотации IDEF3.
курсовая работа [3,8 M], добавлен 14.12.2012Сравнительный анализ гостиничных информационных систем. Анализ и выбор CASE-средств для моделирования бизнес-процессов. Визуальная и математическая модели предметной области, выбор архитектуры и платформы информационной системы, построение базы данных.
дипломная работа [1,4 M], добавлен 20.07.2014Характеристика основных методов проектирования: в SADT, UML. Техническое задание на информационную систему. Создание модели в стандарте SADT (IDEF0). Декомпозиция родительской модели. Создание таблиц базы данных и связей между ними, бизнес логики.
курсовая работа [1,0 M], добавлен 14.11.2017Анализ предметной области, этапы проектирования автоматизированных информационных систем. Инструментальные системы разработки программного обеспечения. Роль CASE-средств в проектировании информационной модели. Логическая модель проектируемой базы данных.
курсовая работа [410,6 K], добавлен 21.03.2011Создание контекстной диаграммы информационной системы библиотеки. Основные компоненты и особенности ведения каталогов книг и читателей. Моделирование систем поиска и формирования заказов. Разработка диаграммы дерева узлов и логической модели базы данных.
курсовая работа [1,1 M], добавлен 24.06.2013Роль инструментальных средств проектирования в создании информационной системы. Преимущества CASE-средств разработки Bpwin и Erwin, системы поиска, исправления ошибок модели данных Model Validator. Разработка модели процессов документооборота предприятия.
контрольная работа [2,2 M], добавлен 24.06.2012Методика и основные этапы построения модели бизнес-процессов верхнего уровня исследуемого предприятия, его организационной структуры, классификатора. Разработка модели бизнес-процесса в IDEF0 и в нотации процедуры, применением Erwin Data Modeler.
курсовая работа [1,6 M], добавлен 01.12.2013- Разработка информационной системы для автоматизации учета ремонта электрооборудования на предприятии
Архитектура и функции информационной системы для автоматизации учета ремонта электрооборудования. Построение модели прецедентов, потоков данных и процессов в стандарте IDEF0. Проектирование концептуальной и логической модели интегрированной базы данных.
курсовая работа [442,9 K], добавлен 06.08.2013 Модели данных в управлении базами данных. Концептуальные модели данных. Роль баз данных в информационных системах. Реляционная модель данных. Определение предметной области. Построение модели базы данных для информационной системы "Домашние животные".
курсовая работа [1,9 M], добавлен 19.04.2011История возникновения стандарта IDEF0. Синтаксис и семантика модели, ее границы и связи, действия. Принципы ограничения сложности IDEF0-диаграмм. Особенности национальной российской практики применения функционального моделирования средствами IDEF0.
курсовая работа [50,8 K], добавлен 02.06.2015Структура отдела главного технолога, взаимоотношения с другими подразделениями. Создание модели информационной системы с помощью ERwin Process Modeler r7.3. Диаграмма декомпозиции первого уровня. Разработка модели базы данных технологического процесса.
курсовая работа [423,2 K], добавлен 08.07.2012Разработка структуры информационной системы с использованием СУБД MS Access. Моделирование бизнес-процессов с помощью IDEF0-диаграмм. Проектирование приложения в среде Delphi. Физическая реализация структуры базы данных. Создание интерфейса системы.
отчет по практике [3,4 M], добавлен 07.01.2015Анализ бизнес-процессов предприятия. Определение сущностей и связей между ними. Создание таблиц, запросов, отчетов и форм. Построение логической модели информационной системы. Разработка программного обеспечения. Инструкция по использованию базы данных.
дипломная работа [3,1 M], добавлен 16.08.2015Анализ информационной системы ИНЭК "Страховщик". Описание предметной области с использованием модели "сущность-связь". Моделирование бизнес-процессов с помощью IDEF0-диаграмм. Проектирование и разработка приложения в среде Delphi и создание интерфейса.
отчет по практике [4,9 M], добавлен 28.12.2014- Разработка серверной части информационной системы для сопровождения процесса выдачи заработной платы
Построение use case диаграммы. Проектирование базы данных. Концептуальная модели 1-уровня (диаграмма последовательности действий). Мапирование реляционной модели в метамодель. Логическая реализация метамодели. Скрипты, заполнение таблиц, создание выборок.
курсовая работа [1,4 M], добавлен 28.12.2011 Создание логической модели данных. Назначение кнопок Erwin Toolbox. Создание БД в СУБД InterBase. Использование утилиты WISQL. Создание Script-файла. Перенос структуры данных с одного сервера на другой. Синхронизация каталога БД и текущей модели.
курсовая работа [4,6 M], добавлен 26.11.2011Понятие информационных систем и их классификация, типы и история развития, структура и компоненты. Создание информационной модели и обоснование выбора модели данных. Внутренняя среда предприятия, организация на нем документооборота. Средства базы данных.
курсовая работа [1,0 M], добавлен 17.04.2016
