2018_МетодУказ-к_КР_по_БД (pdf.io). Н. Э. Баумана Ревунков Г. И., Ковалева Н. А., Силантьева Е. Ю., Виноградова М. В., Маслеников К. Ю. Методические указания
 Скачать 3.16 Mb.
|
|
Министерство науки и высшего образования РФ Московский государственный технический университет им. Н.Э. Баумана __________________________________________________________________________ Ревунков Г.И., Ковалева Н.А., Силантьева Е.Ю., Виноградова М.В., Маслеников К.Ю. МЕТОДИЧЕСКИЕ УКАЗАНИЯ К КУРСОВОЙ РАБОТЕ ПО ДИСЦИПЛИНЕ "БАЗЫ ДАННЫХ" Москва 2019 г. УДК 004.65 ББК 32.973.2 Р32 Факультет "Информатика и системы управления" Кафедра "Системы обработки информации и управления" Предисловие В настоящее время практически любая автоматизированная информационная система (банк данных) использует базы данных. Для локальных банков данных широко используются реляционные системы управления базами данных. Курсовая работа выполняется по дисциплине "Базы данных". Целью курсовой работы является закрепление теоретических знаний и навыков, полученных в ходе изучения дисциплин "Модели данных" и "Базы данных". Предполагается, что предварительно студенты изучали дисциплину "Программирование". Тематика курсовой работы связана с проектированием локального банка данных для конкретной предметной области. По итогам выполнения курсовой работы студенты приобретают навыки профессиональных компетенций , предусмотренных основной профессиональной образовательной программой по направлению подготовки 09.03.01 "Информатика и вычислительная техника" (бакалавр): СОПК-2 - способность осваивать методики использования программных средств для решения практических задач (ОПК-2); СПК-1 - способность разрабатывать модели компонентов информационных систем, включая модели баз данных и модели интерфейсов "человек - электронно-вычислительная машина (ПК-1): уметь создавать модели баз данных для локального банка данных; разрабатывать базы данных, используя программные средства СУБД MS ACCESS, CУБД MS SQL SERVER; разрабатывать приложения в средах СУБД MS ACCESS, C#. Авторы надеются, что данные методические указания будут полезны всем читателям в их начальной практической деятельности по созданию локальных банков данных. Введение Курсовая работа по курсу «Базы данных» выполняется в течение 4 семестра 2 курса в рамках дисциплины «Базы данных». Основой для курсовой работы являются лекции и лабораторно-технологический практикум в течение 3 семестра 2 курса по дисциплине «Модели данных». Задание на лабораторный практикум – на разработку автоматизированной информационной системы, студент получает на первой лекции (первая неделя сентября) по курсу «Модели данных». Это задание также является заданием и для курсовой работы. В течение 3 семестра на лабораторном практикуме студент практически реализует автоматизированную информационную систему в виде локального банка данных на базе СУБД «MS ACCESS» в учебных залах. Можно использовать собственные ноутбуки (с разрешения преподавателя). Практическую реализацию АИС на СУБД «MS ACCESS» студент защищает преподавателю с оценкой, которая затем учитывается при защите лабораторного практикума и в дальнейшем – при защите курсовой работы. В конце 3-го семестра студент подготавливает отчет по лабораторному практикуму [ ] и защищает в целом свою работу за семестр. (В конце 3-го семестра у него 2 зачета (по состоянию на декабрь 2018 г.) – по лабораторным работам – обычный зачет, и по лабораторному практикуму – дифференцированный зачет – с оценкой). В течение 4-го семестра студент работает над курсовой работой. Предыдущую практическую реализацию АИС на базе СУБД «MS ACCESS», выполненную в 3-ем семестре, студент переводит в новую реализацию на базе инструментов СУБД «MS SQL SERVER» и пакета C#, оформляет документацию и защищает курсовую работу. Место дисциплины в учебном процессе Тематика курсовой работы в рамках данной дисциплины связана с проектированием баз данных и приложений для конкретной предметной области. Цель курсовой работы - закрепление теоретических знаний, полученных в ходе лекций, приобретения навыков проектирования баз данных, накопление опыта работы с СУБД «MS Access», «MS SQL SERVER», а также опыта создания приложений на базе инструментов MS Access и C#. Курсовая работа выполняется в соответствии с заданием и состоит из следующих частей: макет АИС (база данных и прикладные программы) на MS Access (выполняется входе лабораторного практикума по курсу «Модели данных»); макет АИС (база данных на MS SQL-server и прикладные программы на С#) выполняется входе лабораторных работ по курсу «Базы данных»; расчетно-пояснительная записка; графическая часть. Графическая часть курсовой работы состоит из следующих листов формата А4 : тема курсовой работы, цель, состав решенных задач, итоги; графическая модель ПрО (изображение предметной области); функциональная модель ПрО в нотациях IDEF0, DFD; инфологическая модель ПрО; даталогическая модель ПрО (схема базы данных); схема работы системы; структурная схема системы; граф диалога пользовательского интерфейса. Материалы в расчетно-пояснительной записке к курсовой работе должны быть расположены в следующем порядке: Титульный лист. Задание на выполнение курсовой работы. Аннотация. Содержание. Список сокращений и обозначений. Введение. 1 Анализ предметной области. 1.1 Графическая модель предметной области. 1.2 Описание предметной области. 1.3 Описание категорий пользователей, их запросов и сообщений. 1.4 Ограничения предметной области. 1.5 Описание входных документов и сообщений. 1.6 Описание выходных документов и сообщений. 2 Функциональная модель предметной области. 2.1 Описание функциональных задач каждого пользователя системы. 2.2 Спецификационный вариант функциональной модели ПрО. 2.3 Модель предметной области в нотации IDEF0 (граф.схема и описание). 2.4 Модель предметной области в нотации DFD (граф.схема и описание). 3 Инфологическая модель предметной области. 3.1 Графическая диаграмма инфологической модели. 3.2 Спецификационный вариант инфологической модели. 3.3 Графические диаграммы связей атрибутов для каждой сущности. 4 Выбор СУБД. 5 Даталогическая модель предметной области. 5.1 Графическая диаграмма. 5.2 Спецификационный вариант даталогической модели. 6 Схема работы системы. 6.1 Графическая схема. 6.2 Описание графической схемы. 7 Структурная схема системы. 7.1 Графическая схема . 7.2 Описание структурной схемы. 8 Граф-диалога системы. 8.1 Графическая схема . 8.2 Описание граф-диалога. 9 Интерфейс пользователя. 9.1 Экранные формы. 9.2 Запросы. 9.3 Отчеты. 10 Руководство пользователя. 11 Программа и методика испытаний. 12 Заключение. 13 Литература. 14 Приложения. 14.1 Техническое задание. 14.2 Графическая часть. 14.3 Доклад по курсовой работе. 14.4 Другие приложения по решению автора курсовой работы (если надо). Наполнение разделов расчетно-пояснительной записки. Расчетно-пояснительная записка оформляется на протяжении выполнения курсовой работы. Необходимо придерживаться следующего наполнения, которое будет описано ниже. Титульный лист должен быть оформлен в соответствии с рис.1. Бланк титульного листа (и бланк задания) следует скачать в электронном университете (справочные модули / методические документы / бланки курсовой работы). Рису. 1 – Пример оформления титульного листа Задание на выполнение курсовой работы изображено на рис. 2. В графе задание необходимо написать о разработке системы, которая должна отвечать на определенные запросы исходя из предметной области, перечислить основные модели, схемы, документы практические реализации, которые будут созданы в ходе выполнения курсовой и лабораторных работ. В графе «перечень графического материала» необходимо описать перечень создаваемых графических листов, входящих в приложение к работе. График выполнения курсовой работы надо смотреть в семестровом учебном плане. Обычно: 25% – к 4 неделе; 50% – к 8 неделе; 75% – к 12 неделе; 100% – к 15 неделе. Рис. 2 – Пример оформления задания на курсовую работу «Раздел «Аннотация» содержит краткое, но в тоже время, точное описание всей курсовой работы (объем - 15-20 строк печатного текста). «Раздел «Содержание» – указатель заголовков частей и параграфов расчетно- пояснительной записки курсовой работы, определяет ее структурирование. «Раздел «Список сокращений и обозначений» содержит основные сокращения слов, аббревиатур, которые используются в тексте расчетно-пояснительной записки. «Раздел «Введение» (1 – 3 страницы) включает краткий обзор предметной области, цели создания и проектирования автоматизированной системы и ее базы данных, предполагаемые результаты и их применение, задачи решаемые в ходе выполнения курсовой работы. Раздел «Анализ предметной области». С точки зрения проектирования баз данных в рамках системного анализа, необходимо провести подробное словесное описание объектов предметной области и реальных связей, материальных и информационных потоков, которые присутствуют между описываемыми объектами. Выделяют два подхода к выбору состава и структуры предметной области: функциональный подход – реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и задач, для обслуживания информационных потребностей которых создаются система и база данных; предметный подход – информационные потребности будущих пользователей базы данных жестко не фиксируются. В описание предметной области включаются объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. Итогом системного анализа является подробное описание предметной области: информация об объектах предметной области, которая требуется для решения конкретных функциональных задач системы, и которая должна храниться в базе данных. Детально описываются ограничения предметной области, определяются основные пользователи и их роли в системе, входные и выходные документы и сообщения, требования, предъявляемые заказчиками системы. В данном разделе разрабатывается графическая модель (графическое изображение) предметной области – основные объекты, материальные и информационные потоки и другие элементы предметной области, которые могут помочь улучшить взаимопонимание между заказчиком АИС и разработчиками банка данных. На рис. 3 приведены примеры графической модели предметной области Раздел «Функциональная модель предметной области». Здесь приводятся все функциональные задачи для описанных в анализе предметной области пользователей системы отдельно. На рис.4 приведен пример спецификационного варианта функциональной модели. Подраздел «Модель предметной области в нотации IDEF0». Данный раздел необходимо разбить на две составляющие: графическая диаграмма предметной области в нотации IDEF0, в которой описывается где расположена данная схема, и описание модели в данной нотации, где необходимо расписать каждый построенный уровень модели по составляющим. Рис. 3. Примеры графической модели предметной области. Методология структурного анализа и проектирования (SADT – Structured Analysis and Design Technique) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель – это модель, описывающая функциональную структуру объекта на основании иерархии взаимосвязанных диаграмм с требуемой степенью детализации. Рис. 4 –Пример спецификационного варианта функциональной модели Функциональный блок представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. Блок должен иметь название в глагольном наклонении. На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение и определяет способ взаимодействия дуги с блоком: верхняя сторона имеет значение «Управление» (Control); левая сторона имеет значение «Вход» (Input); правая сторона имеет значение «Выход» (Output); нижняя сторона имеет значение «Механизм» (Mechanism). Дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. В IDEF0 различают пять типов стрелок. Вход (Input) – материальные объекты или информация, которые используются или преобразуются работой для получения результата (выхода). Управление (Control) – правила, стратегии, процедуры, стандарты, ограничения на бюджет и время, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Управление влияет на работу, но не преобразуется работой. Выход (Output) – материальный объект или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Механизм (Mechanism) – ресурсы, которые выполняют работу, например, персонал предприятия, станки, устройства и т. д. Построение модели начинают с контекстной диаграммы, которая отражает общую информацию о системе, далее начинают проводить декомпозицию. Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. На рис.5 приведен пример функциональной диаграммы 1-го уровня в нотации IDEF0. Приведем пример описания одного из блоков модели: 1. Авторизация Вход: логин, пароль, запрос о входе в систему; Управление: уровни доступа, правила работы с системой; Выход: успешный вход в систему; Механизм: метеоролог, сервер, ПО, менеджер. …………………………………………………………………………… Рис. 5– Пример функциональной диаграммы в нотации IDEF0 Подраздел «Модель предметной области в нотации DFD» Диаграммы потоков данных (Data Flow Diagramming, DFD) представляют собой иерархию процессов, которые связаны между собой потоками данных. Диаграммы показывают, как обрабатывает информацию каждый процесс, как процессы связаны друг с другом, а также как работает сама система, каким образом она обрабатывает поступающие данные. На рис. 6 приведен пример диаграммы DFD. Области применения диаграмм потоков данных: моделирование функциональных требований к проектируемой системе; моделирование существующего процесса движения информации; описание документооборота, обработки информации; дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота; проведение анализа и определения основных направлений реинжиниринга информационной системы. Раздел «Инфологическая модель предметной области» Для описания предметной области наиболее часто используется модель «сущность– связь», предложенная П. Ченом в 1976 году. Сокращенно такую модель называют ER- моделью от английского названия «Entity–Relationship». Диаграмма модели имеет лексикографическую структуру, т.е. включает в себя текст и элементы графики. Из названия модели понятно, что основными ее структурными элементами будут объекты и связи между ними. Рисунок 6 – Пример функциональной модели в нотации DFD Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного объекта. Атрибут должен иметь имя, уникальное в пределах данной сущности. Набор атрибутов сущности должен быть таким, чтобы можно было однозначно найти требуемый экземпляр сущности. Первичный ключ сущности – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. В терминах модели «сущность–связь» типы объектов обозначаются прямоугольниками, а свойства – овалами. Внутри прямоугольника записывается название типа, внутри овала – название свойства. Связь - это ассоциация, выявленная между сущностями, и показывающая как взаимодействуют сущности между собой. Название типа связи в пределах инфологической модели должно быть уникальным. Наиболее часто используются бинарные связи. Различают следующие виды бимнарных связей: связь 1:1, «один-к-одному»; связь 1:M, «один-ко-многим» (или M:1, «многие-к-одному»); связь M:N, «многие-ко-многим». Не все СУБД могут реализовывать связь «многие-ко-многим». Поэтому для таких СУБД при переходе к даталогической модели необходимо разбивать данный вид связи на две функциональных связи : 1:M «один-ко-многим» и M:1, «многие-к-одному». Спецификационный вариант инфологической модели. Данный пункт расчетно-пояснительной записки включает следующее: описание всех типов атрибутов с указанием их типов значений; описание всех типов сущности, например: СОТРУДНИК (ТАБЕЛЬНЫЙ НОМЕР , ФИО, ДОЛЖНОСТЬ, ОКЛАД); описание всех типов связей; описание связей между атрибутами для каждого типа сущности (см. рис.7 ). Рис. 7 – Пример связи между атрибутами сущности Далее необходимо определить в какой нормальной форме находится разработанная БД. Одним из преимуществ реляционной модели является наличие формального механизма оценки качества логической структуры БД с помощью теории нормализации. Нормализация – это процесс приведения структуры реляционных отношений к форме, обладающей лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т. е. исключена избыточность информации. Вводится понятие нормальных форм (НФ) отношений, каждой из которых соответствует определенный набор ограничений. Отношение находится в данной нормальной форме, если удовлетворяет указанным ограничениям. Пусть R – реляционное отношение, а X и Y – некоторые подмножества атрибутов этого отношения. X функционально определяет Y тогда и только тогда, когда для каждого значения множества X существует только одно значение множества Y Отношение находится в первой нормальной форме (1НФ) тогда и только тогда, когда оно содержит только скалярные значения атрибутов и ни один из ключевых атрибутов не имеет значения NULL. Реляционное отношение находится во второй нормальной форме (2НФ), если оно удовлетворяет определению 1НФ и все его атрибуты, не входящие в первичный ключ, неприводимо зависимы от него. Отношение находится в третьей нормальной форме (3НФ), если оно удовлетворяет определению 2НФ и ни один из его неключевых атрибутов не зависит функционально от любого другого неключевого атрибута. Определение 3НФ не совсем подходит для анализа структуры отношений, соответствующих перечисленным ниже условиям: отношение имеет два или более потенциальных ключа; потенциальных ключей несколько, и они являются сложными; у сложных ключей есть хотя бы один общий атрибут. В этом случае, обычно используют более «сильную» нормальную форму Бойса- Кодда (НФБК). Отношение находится в нормальной форме Бойса-Кодда, тогда и только тогда, когда все детерминанты нетривиальных и неприводимых ФЗ являются потенциальными ключами. На практике процесс нормализации часто заканчивается приведением отношений БД в соответствие требованиям НФБК. Но в некоторых случаях требуется привести отношение к более старшей НФ. Раздел «Выбор СУБД» Здесь необходимо описать, какие СУБД были использованы в курсовой работе для проектирования системы: их преимущества, есть ли какие-нибудь недостатки, с помощью каких технологий выполнены пользовательские приложения. Раздел «Даталогическая модель предметной области» В данном разделе приводятся пояснения графической диаграммы, а также спецификационный вариант даталогической модели. Раздел «Схема работы системы» Схема работы системы -- это описание алгоритма, по которому осуществляется работа всей разрабатываемой системы. Построение графической диаграммы осуществляется согласно ГОСТ 19.701-90 ЕСПД Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения. В расчетно-пояснительной записке приводится графическая диаграмма, а также ее краткое описание. На рис. 8 изображен фрагмент графической диаграммы схемы работы системы Рис. 8 – Фрагмент схемы работы системы Раздел «Структурная схема системы» В данном разделе необходимо описать структурную схему создаваемой системы. Структурная схема системы состоит из разработанных подсистем, или реализованных групп функций с их дальнейшей детализацией. Также необходимо изобразить связь каждого блока схемы с отчетами и таблицами БД. На рис. 9 приведен фрагмент структурной схемы системы. Рис. 9 – Фрагмент структурной схемы системы Раздел «Граф диалога системы» Граф диалога системы – это схема управления в интерфейсе пользователя. Граф диалога системы представляет собой ориентированный взвешенный граф, каждой вершине которого сопоставлено конкретное окно, выводимое на экран. Каждое окно схематично представляет определенное состояние диалога пользователя, характеризующееся набором доступных пользователю в этом окне управляющих элементов. Каждый из управляющих элементов предназначен для активации конкретных действий в системе. В расчетно-пояснительной записке необходимо привести графическую схему графа диалога (см. рис. 10), а также его описание – изложение графической схемы графа диалога в текстовом виде, т.е. описание всех переходов, действий результатов. Рисунок 10 – Фрагмент графа диалога Для упрощения построения графа диалога можно сделать следующие примечания: на каждой дочерней форме существует кнопка «Возврат», осуществляющая переход пользователя на уровень выше; для перехода между записями в формах используется типовой навигатор СУБД. Раздел «Интерфейс пользователя» В данном разделе необходимо описать разработанный интерфейс пользователя. По следующим пунктам: экранные формы; запросы; отчеты. Экранные формы являются «лицом» системы, создают первое впечатление у пользователя. Поэтому очень важно, чтобы интерфейс был простой, понятный любому пользователю, но в тоже время функциональный. Приведем некоторые принципы проектирования экранных форм: все экранные формы должны иметь уникальные заголовки; курсор по умолчанию должен перемещаться слева направо, а затем сверху вниз; экранная форма должна обнаруживать ошибочно введенные данные; экранная форма не должна состоять из множества страниц; пользователи не должны ничего запоминать, записывать при переходе от одной формы к другой; использование специальных эффектов должно быть сведено к минимуму. В расчетно-пояснительной записке необходимо привести описание всех разработанных пользовательских форм, а также привести их изображения в двух форматах: форма на MS Access и C#. Запрос – это средство выбора необходимых данных из базы данных. В расчетно- пояснительной записке необходимо привести запросы в конструкторе MS Access, их описание, а также запрос на языке SQL. Отчет – это представление данных в определенном формате, которое выводится на экран, печать или файл. В расчетно-пояснительной записке необходимо привести описание отчетов и их изображения в MS Access и C#. Рисунки экранных форм, запросов и отчетов могут быть приведены в приложении. Раздел «Руководство пользователя» Руководство пользователя (руководство по эксплуатации, руководство оператора, в дальнейшем РП) – это документ, назначение которого состоит в том, чтобы предоставить будущим пользователям системы помощь в использовании разработанной системы. РП помимо текстовых описаний содержит изображения. В случае программного обеспечения, в РП включают снимки экрана, при описании аппаратуры — простые и понятные рисунки или фотографии. На рис. 11 приведен фрагмент РП. Структура и содержание документа РП автоматизированной системы регламентированы подразделом 3.4 документа РД 50-34.698-90. Структура и содержание документов, а также ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79. Обычно структура РП похожа на приведенную ниже: общие сведения; установка и первоначальная настройка; основные понятия и определения; интерфейс пользователя; работа с программой; пользовательская настройка; сообщения об ошибках и аварийных ситуациях Рисунок 11 – Фрагмент руководства пользователя системы Раздел Программа и методика испытаний (ПМИ) Данный вид документа оформляется в соответствии с ГОСТ 19.105-78, и должен содержать следующие пункты: объект испытаний; цель испытаний; требования к программе; требования к программной документации; состав и порядок испытаний; методы испытаний. ПМИ может содержать дополнительные материалы – графики, таблицы, тестовые примеры и их контрольные распечатки, что необходимо привести в данной курсовой работе. В зависимости от особенностей документа допускается вводить дополнительные разделы. Приведем ниже возможный вид фрагмента программы и методики испытаний для пункта «Состав и порядок испытаний» - рис.12: Рис.12. Фрагмент программы и методики испытаний. Разделы курсовой работы «Руководство пользователя» и «Программа и методика испытаний» могут быть оформлены как приложения к ней. Раздел «Заключение» В данной части расчетно-пояснительной записки к курсовой работе приводятся основные полученные результаты, кратко описывается полученная система, ее область применения, основные преимущества и недостатки, как систему можно улучшить при дальнейшем использовании. Раздел «Литература» В данном разделе приводится список литературы, который был использован в течение работы над курсовой работой. Общее количество источников информации в списке должно содержать, как правило, не менее 7-10 наименований, ссылки на которые имеются в тексте расчетно- пояснительной записки, в том числе и ссылки из сети Интернет. Обязательно должны быть источники за последние 5 лет. Список литературы оформляется по ГОСТ 7.1 2003 «Библиографическая запись. Библиографическое описание. Общие требования и правила составления». Раздел «Приложения» Здесь необходимо привести все разработанные приложения к курсовой работе. Приложение 1 – это Техническое задание (ТЗ), которое оформляется в соответствии с ГОСТ 34.602-89. ТЗ должно состоят из следующих пунктов: 1. Наименование проекта 2. Основание для разработки 3. Назначение разработки 4. Исполнитель 5. Технические требования к системе 5.1. Общие требования 5.2. Функциональные требования 5.3. Требования к входным и выходным данным 5.4. Требования к программному обеспечению 5.5. Требования к техническому обеспечению 5.6. Требования к лингвистическому обеспечению 5.7. Требования к условиям эксплуатации 5.8. Требования к надежности 6. Требования к документации 8. Стадии и этапы разработки 9. Порядок контроля и приема задания 10. Дополнительные условия Приложение 2. Графическая часть. Графическая часть курсовой работы состоит из следующих листов формата А4 : Лист 1. Тема курсовой работы, цель. Графическая модель ПрО (изображение предметной области). Лист 3. Функциональная модель ПрО в нотации IDEF0. Лист 4. Функциональная модель ПрО в нотации DFD. Лист 5. Инфологическая модель ПрО. Лист 6. Даталогическая модель ПрО (схема базы данных). Лист 7. Схема работы системы. Лист 8. Структурная схема системы. Лист 9. Граф диалога пользовательского интерфейса. Приложение 3.Доклад по курсовой работе. В докладе необходимо рассказать о цели работы, по листам и о достигнутых результатах. Приложение 4 и так далее. Начиная с Приложения 4 можно оформлять как приложение РП, ПМИ, а также другую объемную информацию, которая не поместилась в расчетно-пояснительную записку из-за ее ограниченного объема, например, экранные формы, дополнительные схемы IDEF0 и их описание и др. Оформление расчетно-пояснительной записки к курсовой работе РПЗ должна быть распечатана на одной стороне листа бумаги формата А4 (210х297 мм) шрифтом черного цвета Times New Roman 14 размера, кроме фрагментов кода программ, для которых необходимо использовать шрифт Courier New. В РПЗ необходимо соблюдать следующие размеры полей страницы: левое – 3 см, правое – 1 см, нижнее – 2 см, верхнее – 2 см. Выравнивание текста – по ширине, без отступов и интервалов. Отступ первой строки абзацев – 1,25 см. Междустрочное расстояние – 1,5 строки. Номер страницы проставляется внизу листа и должен располагаться по центру страницы, симметрично тексту. Все листы РПЗ должны быть пронумерованы, включая титульный лист, номер на котором не ставится. На все таблицы в тексте РПЗ должны быть ссылки. Таблица должна располагаться сразу после абзаца, в котором на нее имеется первая ссылка или на следующей странице, если после соответствующего абзаца недостаточно места. По горизонтали таблица должна быть выровнена по центру относительно текста и сопровождаться номером и названием, которые указывают над таблицей отдельным абзацем, начинающимся от правого края таблицы. При переносе части таблицы на следующий лист шапку таблицы следует повторить, если она небольшая, в противном случае следует пронумеровать графы. Над такой частью таблицы пишут слово «Продолжение» и указывают номер таблицы. На все иллюстрации в тексте РПЗ должны быть ссылки. Иллюстрация должна располагаться сразу после абзаца, в котором на нее имеется первая ссылка или на следующей странице отдельной строкой без обрамления текстом в соответствии с рисунком справа. Приложение. Примеры Пример аннотации. Курсовая работа «Автоматизированная информационная система «Районная больница» посвящена разработке автоматизированной информационной системы, предназначенной для повышения эффективности работы медицинского учреждения (больницы) и автоматизации рутинных задач сотрудников больницы. При введении в эксплуатацию в больнице данная АИС позволит автоматизировать сбор и хранение информации о пациентах и их историях болезни, сотрудниках, даст возможность удобно хранить информацию о медикаментозном обеспечении и возможностях больницы. В процессе выполнения курсовой работы было проведено исследование предметной области, была разработана структура системы, построены функциональная, инфологическая и даталогическая модели, спроектирован пользовательский интерфейс. По итогам работы была реализована автоматизированная информационная система (АИС) «Районная больница». Расчетно-пояснительная записка курсовой работы содержит ХХ страниц (ХХ страниц с приложением), ХХ таблиц и ХХ иллюстраций. В процессе выполнения данной работы были использованы ХХ литературных и ХХ интернет источников. Графическая часть курсовой работы содержит Х листов формата А4. Пример введения. Курсовая работа на тему «Автоматизированная информационная система «Районная больница» посвящена разработке системы, позволяющей автоматизировать рутинную деятельность сотрудников медицинского учреждения (больницы) с целью повышения эффективности и производительности труда и сокращения бумажного документооборота. Автоматизация основной деятельности сотрудников больницы выполняется с целью повышения эффективности их работы и снижения бумажного документооборота. Система позволит обеспечить информатизацию медицинского учреждения и автоматизировать многие рутинные задачи сотрудников больницы. Совершенствование здравоохранения и повышение качества медицинского обслуживания являются важной проблемой социальной политики Российской Федерации. Именно информационные технологии могут внести существенный вклад в решение этой задачи. Наиболее остро проблема наблюдается в отдаленных регионах, где практически отсутствует качественное современное оборудование, медикаментозное обеспечение и квалифицированный персонал, не говоря уже о развитых информационных технологиях. Даже сейчас во многих поликлиниках и больницах основным носителем информации является папка с бумагами. Введение в эксплуатацию в больнице данной АИС позволит автоматизировать сбор и хранение информации о сотрудниках, пациентах и их историях болезни, формировать программу лечения, даст возможность удобно хранить информацию о техническом и медикаментозном обеспечении. В настоящее время уже созданы пакеты программ, позволяющие реализовать АИС больницы и поликлиники. Это пакеты «1С», «МКТ» и другие - рис. . Рис. Однако эти пакеты являются избыточными по реализуемым функциям и требуемым операционно-вычислительным ресурсам для небольших больниц, находящихся в отдаленных, небольших населенных пунктах. В таких больницах необходима АИС, реализующая минимально необходимый набор функций на относительно недорогом наборе операционно-вычислительных ресурсов. Таким образом система, выполняющая необходимый минимум функций для ведения информации о больнице и имеющая простой и понятный для пользователей, не являющихся специалистами в IT-сфере, интерфейс, даст возможность использовать такую автоматизированную информационную систему в небольших региональных больницах и уменьшит затраты на ее внедрение и эксплуатацию. Что и определяет актуальность настоящей разработки. Пример описания предметной области Предметная область АИС «Районная больница» состоит из большого количества сущностей. По правам доступа в системы можно выделить следующие категории пользователей: Администратор системы, которому доступны все таблицы и действия над ними; Младший медицинский персонал, которому доступна работа с пациентами и ресурсами больницы и статистические запросы; Старший медицинский персонал, которому доступна работа с пациентами, просмотр информации о ресурсах больницы и статистические запросы; Менеджер по персоналу, который может работать с данными сотрудниках; Бухгалтер, которому доступен просмотр информации о пациентах, медикаментах и статистические запросы; Среди сущностей неживой природы можно выделить: медикаменты; процедуры; лабораторные исследования; электронный медицинские карты пациентов. Перечень процессов, подлежащий автоматизации Управление информацией о пациентах (добавление, редактирование, удаление). o Управление информацией о сотрудниках (добавление, редактирование, удаление). Управление информацией о медикаментах (добавление, редактирование, удаление). Управление информацией о процедурах (добавление, редактирование, удаление). Управление информацией о лабораторных исследованиях (добавление, редактирование, удаление). Регистрация сотрудников в системе и разграничение доступа. Реализация электронной медицинской карты пациента. Возможность формирования программы лечения для пациентов. Организация коечного фонда (распределение пациентов по палатам). Поиск сотрудников (по фамилии, по должности, по отделению). Поиск пациентов (по фамилии, по фамилии лечащего врача, по датам за период). Поиск медикаментов (по названию, по дате с подсчетом суммы закупки). Поиск процедур (по названию). Поиск лабораторных исследований (по названию). Поиск по палатам (с распределением мест). Функциональные задачи системы. Администратором системы является специалист в области информационных технологий. В его задачи входит обеспечение и поддержание работоспособности системы, а также устранение ошибок и неполадок. Ему доступна работа со всей системой, поэтому обязательно предусмотреть грамотное составление перечня его должностных обязанностей и иметь подписанный с ним договор о сохранении конфиденциальности информации. Младший медицинский персонал (медсестры/медбратья) может: Добавлять, просматривать, редактировать и удалять информацию о пациентах; Добавлять, просматривать, редактировать и удалять информацию о медикаментах; Добавлять, просматривать, редактировать и удалять информацию о процедурах; Добавлять, просматривать, редактировать и удалять информацию о лабораторных исследованиях; Добавлять, просматривать, редактировать и удалять записи в электронной медицинской карте пациента; Добавлять, просматривать, редактировать и удалять информацию программе лечения пациента; Просматривать информацию о сотрудниках; Делать статистические запросы; Просматривать и редактировать информацию о коечном фонде; Старший медицинский персонал может: Просматривать информацию о пациентах; Просматривать информацию о медикаментах; Просматривать информацию о процедурах; Просматривать информацию о лабораторных исследованиях; Добавлять, просматривать, редактировать и удалять записи в электронной медицинской карте пациента; Добавлять, просматривать, редактировать и удалять информацию программе лечения пациента; Просматривать информацию о сотрудниках; Делать статистические запросы; Просматривать информацию о коечном фонде; Менеджер по персоналу может: Добавлять, редактировать и удалять информацию о сотрудниках больницы; Бухгалтер может: Просматривать информацию о пациентах; Просматривать информацию о медикаментах; Делать статистические запросы; Целью данной работы является проектирование и реализация автоматизированной информационной системы, состоящей из серверного и клиентского программного обеспечения. Система должна позволять оперативно редактировать и добавлять новые записи, манипулировать информацией о пациентах и ходе их лечения. Система должна предусматривать разграничение доступа к записям, чтобы только уполномоченные сотрудники больницы имели доступ к редактированию и просмотру записей. Интерфейс системы должен быть прост и понятен пользователю, чтобы любой сотрудник мог работать с системой после небольшой предварительной подготовки. Технология управления с помощью данной АИС должна позволять администрации объективно оценивать степень соблюдения технологической дисциплины, т.е. реально участвовать в управлении лечебно-диагностическим процессом и иметь точные данные о качестве оказываемой помощи, обеспечивать безопасность пациентов, обеспечивать связь с областными и центральными диагностическими центрами, оценивать истинные потребности своих подразделений в финансировании. Пример: Пример: |