Где работает система
Организация, подразделение, процесс, участок деятельности: автосервис, библиотека, склад, учебный отдел, клиника.
Дисциплина РосНОУ
Проектирование информационных систем
Как понять предметную область, построить модель данных, связать её с пользователями и защитить курсовую на «отлично».
Пиков Виталий Александрович
Telegram: @UnderLineSecurity
И
Информацияданные, документы, сообщения, сведения
ПО
Технологииприложение, СУБД, запросы, интерфейсы
Т
Технические средстварабочие места, серверы, сеть, устройства
Слайд 01 / 18
Титульная страница и контакты
Навигация
Что вы найдёте в этом лендинге
Это не просто памятка. Это маршрут выполнения курсовой: от выбора объекта до проверки интерфейса и защиты логики проекта.
Слайд 02 / 18
Карта материала
Базовое определение
Информационная система больше, чем база данных
В курсовой проектируется система, а не отдельная таблица и не набор экранов. База данных является важной частью, но она не заменяет систему целиком.
ИС = информация + программные технологии + технические средства
Если в работе есть только таблицы, но нет функций, пользователей, транзакций и интерфейса, это ещё не проектирование информационной системы.
Слайд 03 / 18
Смысл ИС
Точка старта
Объект
Функция
Результат
Сначала объект и функция
Хорошая работа начинается с ясного ответа: что автоматизируем и для какой функции проектируем систему.
Что система помогает делать
Запись клиента, учёт заказов, выдача документов, обработка заявок, контроль оплаты, планирование расписания.
Что должно измениться
Пользователь быстрее получает данные, меньше ошибается, видит историю операций и формирует нужные документы.
Слайд 04 / 18
Объект и функция
Границы ответственности
Граница ИС проходит по точке контроля
Внутри границы находится то, чем проектируемая система реально управляет. Внешние сервисы, облака, сети и чужие системы описываются как окружение.
Пользователь
ввод
Интерфейс ИС
Приложение
SQL
База данных
Рабочее место
сеть
Внешние ресурсы
Слайд 05 / 18
Границы системы
Маршрут курсовой
Пять связанных этапов проектирования
1
Предметная область
Описать процесс, документы, правила, пользователей, объект и функцию.
2
Концептуальная модель
Выделить сущности, атрибуты, ключи, домены и связи.
3
ER-диаграмма
Построить первую модель в ERwin, затем провести анализ и улучшить её.
4
Физическая БД
Выбрать режим Logical/Physical, целевую СУБД, задать типы данных и показать реальную структуру.
3-5
Интерфейс
Проектировать параллельно с БД: экранные поля, транзакции и атрибуты должны постоянно сверяться.
Интерфейс не откладывается «на потом»: он помогает проверить, хватает ли в модели данных для пользовательских сценариев.
Слайд 06 / 18
Этапы работы
Описание предметной области
Это деловая картина процесса, а не формальная страница
Нужно показать, как сейчас выполняется функция, кто участвует, какие документы входят в процесс и какие документы появляются на выходе.
Процесс
Что происходит по шагам и почему именно так.
Правила
Ограничения, условия, исключения, бизнес-логика.
Документы
Входные формы, выходные отчёты, примеры реквизитов.
Пользователи
Роли, которые выполняют действия в системе.
Слайд 07 / 18
Предметная область
Сущности
Как выделить сущности из текста
Методика простая: выписываем существительные и устойчивые словосочетания, затем проверяем их двумя вопросами.
| Вопрос | Решение |
|---|---|
| Важно ли это для выбранной функции? | Если нет, не включаем в модель. |
| Есть ли собственные атрибуты? | Если да, это кандидат в сущность. |
| Можно ли хранить экземпляры? | Если да, сущность должна быть описана. |
Слайд 08 / 18
Выделение сущностей
Атрибуты, ключи, домены
Атрибут
Ключ
Домен
Каждая сущность должна быть описана строго
Свойство сущности
Берётся из описания процесса, реквизитов документов и данных, нужных пользователю.
Однозначная идентификация
Первичный ключ должен быть уникальным, минимальным, устойчивым и удобным для работы.
Допустимые значения
Тип, размер, диапазон, перечисление, значение по умолчанию или понятное ограничение.
ФИО обычно плохой первичный ключ: совпадения возможны.
Составной ключ допустим, но только когда он действительно нужен.
Производные атрибуты нужно отметить и проанализировать.
Многозначные атрибуты нельзя оставлять без преобразования.
Слайд 09 / 18
Описание данных
Связи
Связь должна иметь смысл для выбранной функции
Недостаточно соединить сущности линиями. Нужно назвать связь глаголом, определить кардинальность, степень участия и объяснить их бизнес-правилом.
Клиент
заказывает
Услуга
Накладная
содержит
Материал
Мастер
выполняет
Ремонт
Слайд 10 / 18
Связи, кардинальность и степень участия
Анализ ER-диаграммы
Проверить
Удалить или объяснить
Проанализировать
Первая диаграмма может быть сырой. Итоговая должна быть обоснованной
M:N
Связь многие-ко-многим напрямую не оставляют. Её раскрывают через ассоциативную сущность.
1:1
Подозрительные связи один-к-одному требуют проверки: возможно, сущности надо объединить.
Лишние связи
Если связь не нужна для функции и транзакций, она создаёт шум и снижает качество модели.
Многозначные атрибуты преобразованы.
Производные атрибуты не ломают модель.
Рекурсивные связи осмыслены или убраны.
Итоговая ER-диаграмма отличается от первой.
Слайд 11 / 18
Анализ модели
Нормализация
1НФ
2НФ
3НФ
До 3НФ: меньше дублей, меньше логических ошибок
Атомарные значения
В ячейке одно значение, нет списков внутри одного поля.
Зависимость от ключа
Неключевые атрибуты зависят от полного первичного ключа.
Нет транзитивных зависимостей
Атрибуты не должны зависеть от других неключевых атрибутов.
Слайд 12 / 18
Нормализация
Пользователи
Роли описываются по функциям, а не только по должностям
В курсовой важно показать, кто работает с системой и какие действия выполняет с данными.
| Неудачно | Лучше |
|---|---|
| Сотрудник | Оператор заявок |
| Менеджер | Пользователь, который оформляет заказ |
| Администратор | Пользователь, который ведёт справочники |
| Директор | Пользователь, который получает отчёты |
Слайд 13 / 18
Роли пользователей
Транзакции
Транзакция показывает, что база поддерживает реальные действия
Список транзакций связывает модель данных с функцией системы. Хороший ориентир: 20-30 операций, из них около 10 подробно показать на модели или в реализации.
Примеры транзакций
Найти клиента по ФИО и телефону. Показать все заказы клиента. Узнать стоимость услуги. Сформировать накладную. Показать материалы по услуге.
Проверка транзакций
Для каждой операции должно хватать сущностей, атрибутов и связей. Если запрос невозможен, модель нужно исправлять.
Слайд 14 / 18
Транзакции
Интерфейс
Поля интерфейса должны совпадать с атрибутами БД
Макет интерфейса нужен не для красоты, а для проверки: пользовательская форма должна работать на данных, которые действительно есть в модели.
Если поле есть на форме, оно должно существовать в БД или вычисляться по понятному правилу.
Если атрибут важен для функции, он должен использоваться в интерфейсе или транзакциях.
Кнопки и элементы управления нужно описать: что делает каждый элемент.
Алгоритм решения должен быть понятен: например, как считается итоговая сумма.
Слайд 15 / 18
Проектирование интерфейса
Оценка «отлично»
Сильная курсовая доказывает логику проекта
Что обязательно
Подробно описана предметная область.
Есть список сущностей, атрибутов, ключей и доменов.
Есть первая и итоговая ER-диаграмма в ERwin.
Есть анализ модели и нормализация до 3НФ.
Создана реальная БД в выбранной СУБД, есть скриншоты структуры.
Сформирован список транзакций, связанных с функцией системы.
Интерфейс соответствует БД: поля формы связаны с атрибутами и транзакциями.
Что усиливает работу
Есть подробный анализ транзакций на логическом и физическом этапах.
Прототип или код как дополнительный плюс.
Выводы написаны собственной логикой, а не как набор формальных фраз.
Слайд 16 / 18
Как получить отлично
Типовые ошибки
Что чаще всего снижает оценку
Нет объекта и функции
Тема есть, а что именно автоматизируется и зачем, не ясно.
Только база данных
Нет пользователей, транзакций, интерфейса и границ системы.
Нет анализа ER
Диаграмма сразу «идеальная», без проверки связей и атрибутов.
M:N напрямую
Не введена ассоциативная сущность для раскрытия связи.
Интерфейс фантазийный
Поля формы не совпадают с атрибутами базы данных.
Нет транзакций
Невозможно доказать, что модель поддерживает реальные действия.
Слайд 17 / 18
Ошибки
Контакты преподавателя
Вопросы по теме курсовой задавайте заранее
Чем раньше вы покажете объект, функцию, первую модель и список транзакций, тем проще исправить проект до защиты.
Пиков Виталий Александрович
Заслуженный доцент Российского нового университета. Преподаватель дисциплин в области информационных систем, информационных технологий и информационной безопасности.
Telegram: @UnderLineSecurityФирменные элементы: логотип и палитра РосНОУ. Материалы: конспект занятия, методические указания к курсовому проекту и чек-лист проверки курсовой.
Слайд 18 / 18
Финальный слайд