Загрузка...
Учебная работа. Контрольная работа: Информационные системы 6
Донбасская Муниципальная Машиностроительная Академия
Контрольная работа
по дисциплине «Информационные системы»
2008 г.
1.
Стратегии разработки административных информационных систем
Административные информационные системы (АИС) создаются для совершения управления и обеспечивают неразрывную связь меж информацией и управлением. Создание АИС – непростая неувязка. Даже для маленьких организаций оно подразумевает разработку ряда подсистем, которые должны соответствовать принципам интеграции и маневренности.
Существенное воздействие на разрабатываемую информационную модель оказывает стратегия (либо система взглядов) относительно организации системы. На практике используют разные сочетания типовых стратегий либо подходов
Общесистемный подход.
Общесистемный подход основывается на предположении, что еще до реализации системы мы неким обоснованным методом можем распознать связи меж частями ее базисной инфы. Процессы сбора, хранения и обработки данных проектируются и реализуются в рамках всей системы в целом. Хотя этот подход является безупречным, его применение в полном объеме может оказаться очень сложным из-за практических, политических, соц заморочек. При уже имеющейся системе проектирование безупречной системы может стать просто академическим упражнением, потому что ее реализация вызовет конструктивные преобразования. По правде, слепое, без определенной технологии, внедрение проектировщиками этого подхода может привести к крушению иллюзий, что и случается в почти всех нынешних вычислительных системах. Но в организациях, которые еще не имеют разработанных систем, работающих и считающихся удовлетворительными, рассматриваемый подход быть может удачно использован. Он является идеализированным и не может в полном объеме применяться в настоящей организации.
Как можно было узреть при рассмотрении 6 подходов, стратегия выбора подхода обязана формироваться с учетом особенностей определенной системы. Следует принимать в расчет такие причины, как размер организации, природа ее деловых операций и опыт. Значительно, что выбор стратегии должен быть произведен опосля кропотливой оценки степени риска и преимуществ вероятных подходов.
2. Нормализация и обычные формы при разработке баз данных
Центральная задачка проектирования базы данных ЭИС -определение количества отношений (либо других составных единиц инфы) и их атрибутного состава.
Задачка группировки атрибутов в дела, набор которых заблаговременно не фиксирован, допускает огромное количество разных вариантов решений. Оптимальные варианты группировки должны учесть последующие требования:
• огромное количество отношений обязано обеспечивать минимальную избыточность представления инфы,
• корректировка отношений не обязана приводить к двусмысленности либо потере инфы,
• перестройка набора отношений при добавлении в базуданных новейших атрибутов обязана быть малой.
Нормализация представляет собой один из более изученных методов преобразования отношений, позволяющих сделать лучше свойства БД по перечисленным аспектам.
Ограничения на значения, хранимые в реляционной базе данных, довольно многочисленны. Соблюдение этих ограничений в определенных отношениях соединено с наличием так именуемых обычных форм. процесс преобразования отношений базы данных к той либо другой обычной форме именуется нормализацией отношений. Обычные формы нумеруются поочередно от 1 по возрастанию, и чем больше номер обычной формы, тем больше ограничений на хранимые значения обязано соблюдаться в соответственном отношении.
Ограничения, обычные для реляционной модели данных, -это многофункциональные и неоднозначные зависимости, также их обобщения. В принципе, огромное количество доп ограничений может расти и соответственно будет возрастать число обычных форм. Используемые ограничения нацелены на сокращение лишней инфы в реляционной базе данных.
Отношение в первой обычной форме (сокращенно 1НФ) — это обыденное отношение с двухуровневой структурой. Недопустимость в структуре дела третьего и следующих уровней является ограничением, определяющим 1НФ дела.
Преобразование ненормализованного дела в база данных в целом характеризуется 1НФ, если все ее дела соответствуют 1НФ.
Последующие обычные формы» (2-ая и 3-я) употребляют ограничения, связанные с понятием многофункциональной зависимости, которое нужно за ранее разглядеть.
Многофункциональные зависимости и ключи
Многофункциональные зависимости определяются для атрибутов, находящихся в одном и том же отношении, удовлетворяющем 1НФ.
Простой вариант многофункциональной зависимости обхватывает 2 атрибута. В отношении R(A,B,…) атрибут А функционально описывает атрибут В, если в хоть какой момент времени любому значению А соответствует единственное
По другому молвят, что В функционально зависит от А (обозначается В = f(A)). 1-ое обозначение оказывается наиболее комфортным, когда число многофункциональных зависимостей вырастает и их связи стают труднообозримыми; оно и будет употребляться в предстоящем. Отсутствие многофункциональной зависимости обозначается А —/-> В.
Можно найти ситуацию А —> В при помощи операции «образ», сказав что огромное количество inB(а) обязано содержать один элемент для хоть какого значения а атрибута А.
Разглядим несколько примеров:
Пример №1.Фамилия студента, группа. Указывает зависимость А -> В (либо В -> А), но не обе зависимости вкупе
R1
ФИО
ГР
Иванов Зуев Смирнов Яшина
1960
1963 1960
1961
Пример №2 магазин и расчетный счет. Наличие взаимно- конкретного соответствия А <-> В.
R2
магазин
Расч
ММЗ
704098
Динамо АТЭ
122095 440162
Пример №3 Студент, Дисциплина. Отсутствие многофункциональной зависимости.
R3
ФИО
Дисциплина
Петров Федин Алешин Петров
Физика Химия Физика Химия
понятие многофункциональной зависимости распространяется на ситуацию с 3-мя и наиболее атрибутами в последующей форме. Группа атрибутов (для определенности А,В,С) функционально описывает атрибут D в отношении T(A,B,C,D,….), если любому сочетанию значений <a,b,c> соответствует единственное части многофункциональной зависимости находится несколько атрибутов, не нуждается в особом рассмотрении. Взаимно-однозначные соответствия для 3-х и наиболее атрибутов также не имеют самостоятельного значения.
Невнимание к способам кодировки атрибутов может привести к несоответствию многофункциональных зависимостей и хранящихся данных, что является суровой проектной ошибкой.
При помощи многофункциональных зависимостей определяется понятие ключа дела, поточнее ряд разновидностей ключей — возможные, первичные и вторичные.
Возможным ключом дела именуется такое огромное количество атрибутов, что каждое сочетание их значений встречается лишь в одной строке дела, и никакое подмножество атрибутов сиим свойством не владеет. Возможных ключей в отношении быть может несколько.
Значимость возможных ключей при обработке данных определяется тем, что подборка по известному значению возможного ключа дает в итоге одну строчку дела или ни одной.
На практике атрибуты возможного ключа дела связываются со качествами тех объектов и событий, информация о которых хранится в отношении. Если в итоге корректировки дела поменялись имена атрибутов, образующих ключ, то это свидетельствует о суровом искажении инфы. Как следует, периодическая проверка параметров возможного ключа дозволяет смотреть за достоверностью инфы в отношении.
Когда в отношении находится несколько возможных ключей, одновременное слежение за ними весьма затруднено и целенаправлено избрать один из их в качестве основного (первичного).
Первичным ключом дела именуется таковой возможный ключ, по значениям которого делается контроль достоверности инфы в отношении.
Применительно к экономической инфы в подавляющем большинстве случаев дела, приобретенные из имеющихся экономических документов, содержат единственный возможный ключ, который является и первичным ключом. Это разъясняется тем, что содержимое экономических документов понимается всеми юзерами идиентично. Дальше будем подразумевать лишь такие дела. наличие 2-ух и наиболее возможных ключей в отношениях с осмысленной информацией можно разъяснить наличием нескольких вероятных методов интерпретации одних и те х же данных. Первичный ключ нередко именуется просто ключ.
Каждое недозволено уменьшить, то найден первичный ключ дела.
Для огромного количества многофункциональных зависимостей существует ряд закономерностей, которые выражаются аксиомами. Познание теорем дозволяет из начального огромного количества многофункциональных зависимостей получать производные зависимости.
Отметим ряд узнаваемых теорем о многофункциональных зависимостях. Атрибуты, фигурирующие в каждой аксиоме, должны находиться в одном и том же отношении.
Аксиома 1
А,В -* А и А,В -> В.
подтверждение основано на том, что в строке <а,Ь> для атрибутов А и В
Аксиома 2
А -> В и А ->С и тогда лишь тогда, когда А -> ВС.
Разглядим случайное 1-го элемента. Приобретенное противоречие обосновывает зависимость А -> ВС.
Назад, если А -> ВС, то imBC(a) содержит один элемент вида <Ь,с> для хоть какого а. Зафиксируем некое один раз, как следует, справедливо А -> В и А ->С.
Аксиома 3
Если А ->» В и В ->С, то А -> С.
Представим, что зависимость А -> С неверна и огромное количество im С(а) содержит наиболее 1-го элемента. Любому значению а соответствует единственное
Броско, что подтверждения других теорем опираются на 1-ые 3 аксиомы, а не доказываются от неприятного.
Аксиома 4
Если А—» В, то АС -> В (С произвольно).
подтверждение
АС —> А (аксиома 1), А -> В (условие), как следует, АС -> В по аксиоме 3.
Аксиома 5
Если А -> В, то АС -> ВС (С произвольно).
подтверждение
АС —» В (аксиома 4), АС —» С (аксиома 1), как следует, АС->ВС по аксиоме 2.
Аксиома 6
Если А ->В и ВС ->D, то АС -* D.
подтверждение
Из А -> В следует АС -> ВС (аксиома 5). ВС -> D (условие), потому АС—> D по аксиоме 3.
2-ая и 3-я обычные формы отношений
Отношение имеет вторую нормальную форму (2НФ), если оно соответствует 1НФ и не содержит неполных многофункциональных зависимостей.
Неполная многофункциональная зависимость — это две зависимости:
· возможный ключ дела функционально описывает некий неключевой атрибут,
· часть возможного ключа функционально описывает тот же неключевой атрибут.
Отношение, не соответственное 2НФ, характеризуется избыточностью хранимых данных.
к примеру:
Т4
магазин
Изделие
Стоимость
План_1999_г.
Салют
М22
50
200
Салют
К14
40
100
АТЭ
М22
50
300
АТЭ
Т62
60
100
Многофункциональные зависимости дела Т4:
Избыточность иллюстрируется тем фактом, что стоимость изделия указывается столько раз, сколько магазинов продают это изделие (изделие М22 в Т4). Переход к 2НФ и соответственно устранение отмеченной избыточности данных соединено с созданием 2-ух отношений заместо начального дела Т4.
Т41
магазин
Изделие
План_1999_г.
Салют
Салют
АТЭ
АТЭ
М22
К14
М22
Т62
200
100
300
100
Т42
Изделие
Стоимость
М22
К14
Т62
50
40
60
Отношение соответствует ЗНФ, если оно соответствует 2НФ и посреди его атрибутов отсутствуют транзитивные многофункциональные зависимости (ФЗ).
метод получения отношений в ЗНФ владеет последующими качествами:
· сохраняет все начальные многофункциональные зависимости, т.е. зависимость, справедливая в R, справедлива и в одном из производных отношений. Это гарантирует получение осмысленных отношений с просто интерпретируемой структурой;
· обеспечивает соединение без утрат, т.е. значения начального дела R могут быть восстановлены из проекций дела R при помощи операции соединения;
· итог декомпозиции в ЗНФ обычно содержит меньше значений атрибутов, чем начальное отношение R (происходит уменьшение избыточности).
3.
Создать информационную систему для учета издержек на Создание продукции
Данная задачка нужна для планово-экономического отдела компании. Ее цель показать издержки на Создание с учетом вещественных и трудовых ресурсов. Результаты задачки демонстрируют как прибыльно для компании выполнение данного заказа производства продукции. Данные о нужной инфы поступают из последующих отделов участвующих в процессе обработки инфы:
· денежный;
· отдела материалов;
· комплектующий отдел;
· расчетный отдел;
· др.
Необходимость либо периодичность выполнения данной задачки зависит от количества выполняемых заказов. Иными словами, она нужна при выполнении хоть какого заказа, выполняемого на предприятии.
Приведенные входные данные имеют укрупненный вид.
Входные таблицы:
1. Сводная таблица учетов заказов.(Costs)
Наименование поля
идентификация
Тип данных
Код записи (ключевое)
ID
Счетчик
Код заказа
KodZak
Текстовое
Дата
Data
Дата/время
Издержки на материалы
Materials
Валютный
Издержки на всп. материалы
SumMaterials
Валютный
Затратные расходы
Overheads
Валютный
Полуфабрикаты/комплектующие
SemiProducts
Валютный
2. Таблица учета работы над заказом профессионалов (MainManufacture)
Наименование поля
идентификация
Тип данных
Код записи (ключевое)
ID
Счетчик
Код заказа
ID_costs
Числовое-целое
Код рабочего
WorkerID
Числовое-целое
Зарплата
Zarpl
Валютный
3. Таблица учета работы над заказом групп работников (SubManufacture)
Наименование поля
идентификация
Тип данных
Код записи (ключевое)
ID
Счетчик
Код заказа
ID_Costs
Числовое-целое
количество работников
Kolvo
Числовое-целое
Средняя зарплата
AvrZarpl
Валютный
4. Таблица работников-специалистов (WorkersList)
Наименование поля
идентификация
Тип данных
Код записи (ключевое)
ID
Счетчик
Табельный номер
TabNo
Числовое-целое
Фамилия, И.О.
FIO
Текстовое
Построим схему данных.
MainManufacture
ID
ID_costs
WorkerID
Zarpl
WorkersList
ID
TabNo
FIO
Costs
ID
KodZak
Data
Materials
SumMaterials
SubManufacture
SubManufacture
ID
ID
ID_Costs
ID_costs
Kolvo
WorkerID
AvrZarpl
Zarpl
Overheads
SemiProducts
Как видно из таблиц, они все имеют главные поля (ID) которые указывают на неповторимость записи в хоть какой из таблиц. Так, в таблицах 2 и 3 есть поля ID_Costs, которые указывают на определенный заказ. Данное условие было нужно, так как неповторимым ключом таблицы COSTS является номер заказа и дата его пуска. Данные поля вкупе представляют достаточно огромное поле-ключ, что будет создавать в остальных таблицах избыточность инфы. Как следует, достаточно таки удобнее ввести одно неповторимое поле, которое и будет служить ключом для связки таблиц. Тоже самое касается и Таблицы WorkersList. Как правило, неповторимым быть может и табельный номер работника, но есть случаи, когда он не уникален: к примеру, табельные номера всякий раз начинаются с начала в новеньком отделе, или это поле имеет буквенно-цифровой вид, что приводит к повышению обработки инфы, так как компьютерная техника работает быстрей с цифрами, чем с знаками.
Представим данные таблиц на примере.
Costs.
ID
KodZak
Data
Materials
SubMaterials
overheads
SemiProducts
1
11-1
01.01.2003
10 000,00 грн.
8 000,00 грн.
2 000,00 грн.
3 000,00 грн.
2
22-2
01.10.2003
12 000,00 грн.
7 500,00 грн.
2 200,00 грн.
3 500,00 грн.
3
33-3
01.11.2003
12 250,00 грн.
8 800,00 грн.
2 300,00 грн.
3 300,00 грн.
MainManufacture
ID
ID_Costs
WorkerID
Zarpl
1
1
1
300,00 грн.
2
1
2
310,00 грн.
3
2
3
325,00 грн.
4
2
2
315,00 грн.
5
3
1
300,00 грн.
6
3
3
320,00 грн.
SubManufacture
ID
ID_Costs
Kolvo
AvrZarpl
1
1
5
200,00 грн.
2
2
7
250,00 грн.
3
3
10
180,00 грн.
4
1
6
175,00 грн.
WorkersList
ID
TabNo
FIO
1
123
Иванов И.И.
2
124
Петров П.П.
3
125
Сидоров С.С.
В процессе работы были сделаны запросы, которые, основываясь на данные таблиц рассчитывают промежные данные для сводного отчета.
запрос “Заработная плата профессионалов” – рассчитывает данные(зарплату) профессионалов по всем выполненным заказам. Это второстепенные данные которые могут быть получены для работников расчетного отдела.
TabNo
FIO
Sum_Zarpl
123
Иванов И.И.
600,00 грн.
124
Петров П.П.
625,00 грн.
125
Сидоров С.С.
645,00 грн.
запрос Calc_Main – рассчитывает данные(зарплату) по заказам о участии профессионалов в процессе выполнения заказа.
toMainBills
ID_Costs
610,00 грн.
1
640,00 грн.
2
620,00 грн.
3
запрос Calc_Sub – рассчитывает данные(зарплату) по заказам о участии рабочих в процессе выполнения заказа.
toSubBills
ID_Costs
2 050,00 грн.
1
1 750,00 грн.
2
1 800,00 грн.
3
Выходными данными будет сводная таблица/отчет о выполнении всех заказов с учетом издержек на выплату зарплаты, также итоговыми суммами по заказу.
отчет о издержек на создание
Код заказа
Дата заказа
Материалы
Неожиданные расходы
Полуфабри-каты
Зарплата
Итого
Главные
Вспомога-тельные
Специа-листы
Рабочие
11-1
01.01.2003
10 000,00 грн.
8 000,00 грн.
2 000,00 грн.
3 000,00 грн.
610,00 грн.
2 050,00 грн.
25 660,00 грн.
22-2
01.10.2003
12 000,00 грн.
7 500,00 грн.
2 200,00 грн.
3 500,00 грн.
640,00 грн.
1 750,00 грн.
27 590,00 грн.
33-3
01.11.2003
12 250,00 грн.
8 800,00 грн.
2 300,00 грн.
3 300,00 грн.
620,00 грн.
1 800,00 грн.
29 070,00 грн.]]>