МОСКОВСКИЙ ТЕХНОЛОГИЧЕСКИЙИНСТИТУТ

Стр 1 из 4Следующая ⇒

МОСКОВСКИЙ ТЕХНОЛОГИЧЕСКИЙИНСТИТУТ

Филиал В Г.ОРЕНБУРГЕ

Кафедра Информатики и автоматизации

КУРСОВАЯ РАБОТА

по дисциплине

«Проектирование автоматизированных информационных систем»

Преподаватель ______________________И.А. Щудро

Исполнитель студент гр. БПАУ ФО – 313

__________________________________

Оренбург 2016

Техническое задание

Содержание

		Стр.
	Титульный лист
	Лист технического задания
	Содержание
	Введение
	Анализ предметной области
1.1	Описание объекта автоматизации. Необходимость автоматизации
1.4	Описание структуры разрабатываемой АИС
1.5	Обоснование выбора моделей данных – средств проектирования базы данных
	Разработка базы данных
2.1	Описание внешнего уровня архитектуры базы данных
2.1.1	Иерархия функций
2.1.2	Формализованное описание предметной области
2.2	Концептуальный уровень архитектуры базы данных
2.2.1	Инфологическая модель предметной области
2.2.3	Даталогическая модель базы данных
2.2.4	Анализ схем реляционных отношений на соответствие 3НФ
2.3	Физическая модель базы данных

Введение

Анализ предметной области

Схема информационных потоков

На предприятии необходимо производить обработку данных на основании ведомостей прихода и расхода. Обслуживаемые торговым отделом клиенты могут относиться к разным категориям, а именно: розничные, мелкооптовые и оптовые. Отнесение клиента к той или иной категории зависит от ряда причин: сумма покупки, частота совершения покупок данным клиентом, дальнейшее сотрудничество и другие.

Схема информационных потоков, подлежащих автоматизации см. слайд

Разработка базы данных

В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни ее архитектуры. Распространены два основных подхода к проектированию систем баз данных: нисходящий и восходящий.

Восходящее проектирование – это достаточно сложная и устаревшая методика, требующая значительного объема мероприятий по нормализации схем реляционных отношений и подходящая для проектирования небольших баз данных. При использовании восходящего метода проектирования сразу формируется схема БД. Термины реляционной модели не предусматривают возможность описания полного смысла предметной области. Неправильное отображение в даталогической модели БД сути предметной области приводит к ошибкам в последующей работе АИС.

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

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

- анализ предметной области. На основе анализа предметной области получают описание внешнего уровня БД, являющееся исходными данными для следующего этапа;

- разработка инфологической модели (ИЛМ). По полученному на предыдущем этапе описанию строится модель данных «сущность-связь»;

- разработка даталогической модели (ДЛМ). На основе ИЛМ предметной области строится ДЛМ базы данных;

- нормализация. Этап представляет собой нормализацию полученной модели;

- формирование физической модели БД на языке определения данных СУБД. На заключительном этапе проектирования строится физическая модель данных с учетом особенностей используемой СУБД.

Инфологическая модель предметной области представлена в приложении А ER-диаграммой, построенной по методологии Ричарда Баркера. Даталогическая модель логической структурой базы данных.

Даталогическая модель БД

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

Реляционное отношение (таблица) – это подмножество декартового произведения k доменов, имеющих смысл с точки зрения рассматриваемой предметной области. Домен – это допустимое множество значений одного типа.

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

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

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

Преобразование связи «один к одному» в ER-диаграмме может иметь разную опциональность, от этого зависит ее отображение в схеме БД. Если связь «один к одному» обязательна с одной стороны, то поле с внешним ключом добавляется в отношение на обязательной стороне, и это отношение становится подчиненным. Опциональность внешнего ключа будет обязательной, если связь не обязательна или обязательна в обоих направлениях. Необходимо выбрать в какую таблицу будет помещен внешний ключ. Если строка в одном отношении создается обычно раньше, чем в другом, то это отношение назначается главным, а внешний ключ создается в подчиненном. Если в одном отношении будет меньше строк, чем в другом, т.е. его размер будет изменяться менее динамично, тогда это отношение назначается главным и внешний ключ создается в подчиненном. Внешний ключ, отражающий такую связь, должен быть уникальным.

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

В соответствии с используемым методом нисходящего проектирования на основе ER-диаграммы предметной области спроектирована даталогическая модель реляционной базы данных (РБД), приведенная на слайде.

Позиция ведомости Номер ПК Количество Код товара ВК1 Код поз пр ВК2 Код ед изм ВК3 Код ведом ВК4

2.3.2. Анализ схем реляционных отношений на соответствие ЗНФ

Нормализация схем отношений необходима для устранения избыточности данных в реляционных отношениях, ведущей к аномалиям при добавлении, обновлении и удалении данных в БД. В теории баз данных определено 6 нормальных форм (НФ).

Схема реляционной базы данных находится в 1НФ, если все отношения соответствуют 1НФ. Схема отношения находится в 1НФ, если все атрибуты имеют атомарные (неделимые) значения. В данной работе все схемы соответствуют 1НФ.

Схема РБД находится в 2НФ, если она находится в 1НФ и все схемы отношений соответствуют 2НФ. Схема отношения находится в 2НФ, если она находится в 1НФ и все не ключевые атрибуты функционально полно зависят от составного первичного ключа. Если в схеме отношения имеется простой первичный ключ (состоит из одного атрибута), то схема по определению находится в 2НФ. Все схемы в данной работе соответствуют 2НФ.

Схема РБД находится в 3НФ, если она находится в 2НФ и все схемы отношений соответствуют 3НФ. Схема отношения находится в 3НФ, если она находится в 2НФ и в ней отсутствуют транзитивные зависимости между не ключевыми атрибутами и первичным ключом.

Полученная схема реляционной базы данных в данной работе соответствует 3НФ.

Заключение

Задания

На курсовое проектирование

1. Автоматизированная информационная система «Индивидуальный план преподавателя»

Описание предметной области.

Для каждого преподавателя (ФИО, Год рождения, Домашний адрес, Контактные телефоны) высшего учебного заведения (Код, Название, Краткое название) на каждый учебный год (Год начала учебного года, Год окончания учебного года) формируется индивидуальный план. В индивидуальном плане отражается общий объем работ преподавателя, который он должен выполнить в течение учебного года. Учет работ ведется по следующей форме:

№	Наименование работы	План	Факт
Осенний семестр	Весенний семестр	Осенний семестр	Весенний семестр

В течение учебного года преподаватель выполняет следующие виды работ (Код, Название Краткое название): «Учебная работа», «Учебно-методическая работа», «Научно-методическая работа», «Научно-исследовательская работа», «Организационно-методическая работа», «Внеучебная работа со студентами», «Прочие виды работ». Необходимо вести учет в часах (целых и долях часов) объем запланированных и фактически выполненных объемов работ для каждого преподавателя по семестрам. Для каждого преподавателя также необходимо фиксировать место работы – факультет (Код, Название, Краткое название), кафедра (Код, Название, Краткое название), занимаемую должность (Код, Название, Краткое название), время работы в этой должности (Дата начала, Дата окончания, Ставка, Дата избрания на должность), кем является преподаватель – штатным сотрудником или совместителем. Также для преподавателя фиксируются:

- ученая степень (Код, Название, Краткое название) – доктор, кандидат; каких наук (Код, Название, Краткое название) – технических, экономических и т.п.; год присуждения;

- ученое звание (Код, Название, Краткое название) – профессор, доцент, с.н.с. и т.п.; год присуждения звания.

Необходимо осуществлять следующую обработку данных:

- формирование для каждого преподавателя итоговой суммы (в часах) запланированных и выполненных объемов работ по семестрам;

- список преподавателей, у которых фактическое значение выполненных работ превышает плановое (факультет, кафедра, ФИО, уч.степень, уч.звание, должность, семестр, кол-во перевыполненных объемов работ);

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