Размещено на http://www.allbest.ru/

Новотроицкий филиал Федерального государственного

автономного образовательного учреждения высшего

профессионального образования

«Национальный исследовательский технологический

университет «МИСиС»

Факультет ЭиИ

Кафедра ПИиУСА

Курсовая работа

По дисциплине: «Базы данных»

Тема: «Имитационная модель работы с базой данных по принципу 1С на примере расчетной ведомости Т-51»

Исполнитель: Коряк Д.С.

Группа 36

Руководитель: Быковец Н.П.

Новотроицк

2012

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1 Характеристика реляционной модели данных. Базовые принципы реляционного подхода. Основные понятия и определения

1.2 Обеспечение отказоустойчивости в SQL-Server

2. ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1 Постановка задачи и описание предметной области

2.2 Логическое проектирование АИС

2.2.1 Проектирование БД

2.2.2 Проектирование интерфейса

2.3 Физическая реализация АИПС

2.4 Инструкция для пользователя

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЯ

ВВЕДЕНИЕ

С развитием экономики усложнились расчёты, связанные с налогообложением, бухгалтерским учётом, статистическими исследованиями. Основной проблемой являлась сложность обработки больших объёмов данных. Вследствие данных обстоятельств появилась необходимость в создании электронных баз данных (БД) и систем управления базами данных (СУБД), позволяющих выполнять над ними такие операции, как добавление новой записи, изменение и удаление существующих записей, а также операции по группировке, систематизации, статистической обработке данных. Автоматизация действий над данными привела к существенному уменьшению временных затрат на их обработку.

Цель курсовой работы: научиться создавать БД и СУБД средствами среды визуального проектирования Borland Delphi 7.0. А так же: осмысление, закрепление изученного теоретического материала и углубление знаний в процессе самостоятельной работе. Получение практических умений и навыков.

Объектом исследования курсовой работы являются БД и СУБД.

Предметом исследования курсовой работы является среда визуального проектирования Borland Delphi 7.0.

Задачи:

1. Разработать алгоритм реализации БД;

2. Разработать приложение для работы с данной БД.

Данная курсовая работа состоит из двух частей:

1. Теоретическая часть;

2. Практическая часть.

Введение, в котором обозначены актуальность и значимость темы, приведены предмет и объект исследования. В первой главе приведен аналитический обзор программных продуктов данного класса (системы управления базами данных), обоснован выбор компонент, используемых для написания программы, и приведено их описание. Во второй главе описана постановка задачи, приведен алгоритм реализации проекта и подробно описана инструкция для пользователя. В заключении приведены общие выводы по аналитической части, указаны результаты работы программы, приведены её достоинства, недостатки и рекомендации по улучшению, вместе с системными требованиями. Список использованных источников включает полную информацию о книгах, использованных при написании курсовой работы. В приложениях А и Б приведены подробные блок-схемы алгоритма и исходный код программы.

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1 Характеристика реляционной модели данных. Базовые принципы реляционного подхода. Основные понятия и определения

Реляционная модель данных.

Реляционная модель данных была предложена математиком Э.Ф. Коддом (Codd E.F.) в 1970 г. РМД является наиболее широко распространенной моделью данных и единственной из трех основных моделей данных, для которой разработан теоретический базис с использованием теории множеств.

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

Элементы отношения называют кортежами. Элементы кортежа принято называть атрибутами. Отношение содержит информацию о сущностях одного типа. Каждый кортеж отношения соответствует одному экземпляру сущности.

Свойства отношений.

Отношение обладает двумя основными свойствами:

- в отношении не должно быть одинаковых кортежей, т.к. это множество;

- порядок кортежей в отношении несущественен.

Отношение удобно представлять как таблицу, где строка является кортежем, столбец соответствует домену (рис. 3, отношение студенты).

Домен 1 . Домен 2 .. . . . домен 3 (ключ) . .домен 4 . . .. .домен 5

Реляционная база данных-- это база данных, разделенная на логически цельные сегменты, называемые таблицами, и внутри базы данных эти таблицы связаны между собой. Реляционная база данных позволяет разделить данные на логичные более мелкие и более управляемые сегменты, что обеспечивает оптимальное представление данных и возможность организации нескольких уровней доступа к данным.

Группа	Фио студента	Номер зачётной книжки	Год рождения	Стипендия
С-72	Волкова Елена Павловна	С-12298	1981	566.40
С-91	Белов Сергей Юрьевич	С-12299	1980	400.00
. . .
С-72	Фролов Юрий Вадимович	С-14407	1981	0

Рис.3. Пример табличной формы представления отношения

Характеристика реляционной модели данных.

Хотя понятие реляционной модели данных первым ввел основоположник реляционного подхода Эдгар Кодд, наиболее распространенная трактовка реляционной модели данных, по-видимому, принадлежит известному популяризатору идей Кодда Кристоферу Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих. Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.

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

В манипуляционной части модели определяются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями и добавлениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка. Мы рассмотрим эти механизмы более подробно в следующих лекциях, а пока лишь заметим, что основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.

Базовые принципы реляционного подхода.

В настоящее время реляционный подход к построению информационных систем является наиболее распространенным. К числу достоинств реляционного подхода можно отнести:

1. наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными;

2. наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации БД;

3. возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти.

В своей статье, опубликованной в журнале «Computer Word», Кодд сформулировал двенадцать приведенных ниже правил, которым должна соответствовать настоящая реляционная база данных.

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

2. Правило гарантированного доступа. Логический доступ ко всем и каждой элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путем использования комбинации имени таблицы, первичного ключа и имени столбца.

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

4. Правило динамического каталога, основанного на реляционной модели. Описание базы данных на логическом уровне должно быть представлено в том же виде, что и основные данные, чтобы пользователи, обладающие соответствующими правами, могли работать с ним с помощью того же реляционного языка, который они применяют для работы с основными данными.

5. Правило исчерпывающего подъязыка данных. Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать, по крайней мере, один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы:

· определение данных;

· определение представлений;

· обработку данных (интерактивную и программную);

· условия целостности;

· идентификацию прав доступа;

· границы транзакций (начало, завершение и отмена).

6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.

7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при добавлении, обновлении и удалении данных.

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

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

12. Правило единственности. Если в реляционной системе есть низкоуровневой язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня (обрабатывающем несколько записей за один раз).

1.2 Обеспечение отказоустойчивости в SQL-Server

Отказоустойчивость часто меряется в "девятках" - процентах, выражающих количество времени в году, когда система находится в рабочем состоянии. Четыре девятки (99,99 %) означают, что система находится в нерабочем режиме не больше 52 минут в году. Пять девяток означают, что режим бездействия в сумме не превышает 5,26 минут в году. А шесть девяток дают допустимое отклонение от работоспособного режима всего 32 секунды в году. В зависимости от особенностей бизнеса, это время может включать время запланированных простоев. По мере стремления достичь большего числа "девяток" отказоустойчивости, приемы управления должны совершенствоваться вместе с технологическими решениями.

Можно достичь пяти девяток отказоустойчивости, делая упор на три основные технологии SQL Server 2000 - отказоустойчивую кластеризацию, перемещение журналов и репликацию. Еще один аспект отказоустойчивости рассматривается как "Восстановление после сбоя тоже означает отказоустойчивость".

Любая дискуссия о высокой отказоустойчивости должна начинаться с обсуждения версий SQL Server, которые можно использовать. Чтобы прийти к конфигурациям с высокой отказоустойчивостью, необходимо задействовать версию SQL Server 2000 Enterprise Edition. Только Enterprise Edition поддерживает отказоустойчивую кластеризацию и пересылку журналов. Хотя можно достичь высокой отказоустойчивости и в версии Standard Edition, в ней ограничения в использовании репликации и настраиваемой пересылке журналов.

Отказоустойчивая кластеризация

Самая главная технология высокой отказоустойчивости в SQL Server 2000 - это отказоустойчивая кластеризация. В статье "Кластеризация SQL Server" Брайан Найт подробно описывает процесс настройки двухузлового кластера SQL Server 2000 в Windows 2000 Enterprise Edition. До SQL Server 2000 отказоустойчивая кластеризация была реализована плохо. Однако разработчики Microsoft полностью переписали отказоустойчивую кластеризацию в SQL Server 2000, и теперь технология стала простой для применения благодаря наличию в SQL Server 2000 многих новых возможностей. Управление кластером осуществляется точно так же, как управление SQL Server, установленным на одной машине. Пока не запустится утилита для настройки кластеризации Cluster Administrator, SQL Server ничем не выдаст того факта, что он работает на кластере. Такая прозрачность упрощает администрирование кластера.

Несмотря на то, что административные процедуры при переходе от одномашинной конфигурации к многомашинной не меняются, вы дополнительно приобретаете важную возможность. В случае аппаратного сбоя кластер автоматически перемещает приложение SQL Server 2000 на другое доступное оборудование в кластере и поддерживает его в рабочем состоянии. Если вы применили определенные приемы, которые я опишу позже, то пользователи никогда не узнают о том, что произошел сбой аппаратного обеспечения. Это важно, поскольку отказоустойчивость на уровне сервера - показатель относительно бесполезный. Важнее отказоустойчивость на уровне настольной системы пользователя, работающего с данными.

Когда на части оборудования (узле), на котором работает SQL Server, происходит сбой, SQL Server отключается. Служба Microsoft Cluster перемещает владельца дисков на другой узел и запускает службу SQL Server. Восстановление ресурсов на кластере происходит примерно за 15 секунд при нормальных условиях. Однако не все понимают последствия отключения и перезапуска SQL Server. Когда SQL Server запускается, выполняется особый последовательный процесс, называемый возвращением к исходному режиму. Важнейшая часть возвращения к исходному режиму - фаза "отменить/повторить исправления" базы данных. Фаза "повторить исправления" всегда короткая; она контролируется настройкой интервала восстановления. В фазе "отменить исправления" все зависит от того, как было запрограммировано приложение. Существенно увеличивать время восстановления кластера могут долго исполняемые транзакции.

Любой кластер SQL Server - это защитный механизм только на уровне аппаратного обеспечения. Кластер SQL Server не защитит вас от сбоев на уровне данных, сбоев приложений логического характера, ошибок пользователей и порчи данных. Чтобы защититься от этих ошибок, вы должны по-новому использовать резервное копирование баз данных. Кроме того, кластер SQL Server не повышает производительность и масштабируемость. Можно иметь много элементов оборудования, действующих как один ресурс, но SQL Server не сможет иметь доступ к ресурсам другого элемента оборудования, а приложение не может масштабироваться на кластере больше, чем на одном узле.

Перемещение журналов

Поскольку использование кластеров защищает только от аппаратных сбоев и не дает возможности освободить процессор или выполнить масштабирование, все необходимое для достижения высокой отказоустойчивости созданием кластера не исчерпывается. Перемещение журналов (log shipping) - это название еще одной технологии высокой отказоустойчивости SQL Server, состоящей в автоматизации резервного копирования базы данных и восстановления на другом сервере.

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

Можно использовать пересылку журналов для достижения многократно повышенной избыточности данных в гораздо большем числе сред, чем в средах с кластерами. Например, Windows Server 2003 Datacenter Edition поддерживает максимум восемь узлов в кластере. Но единственное ограничение в количестве вторичных серверов, которые можно задействовать для перемещения журналов, это объем инфраструктуры, которым вы в состоянии управлять; вы можете создать столько резервных копий, сколько хотите. Перемещение журналов может выполняться на значительно больших расстояниях, чем переключение между узлами кластера. Большинство отказоустойчивых кластеров ограничены расстоянием примерно от 80 до 100 миль. В случае перемещения журналов только возможность провести кабель между первичным и вторичным серверами ограничивает географическое распределение вторичных серверов.

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

При применении последовательных резервных копий журналов транзакций еще одна функция перемещения журналов доступна через настройки восстановления. Если для восстановления использовать настройку WITH STANDBY, то можно сделать вторичный сервер доступным в режиме только для чтения. Этот вторичный сервер - прекрасное место для размещения отчетов и выполнения других операций чтения с первичного сервера, он повышает возможности масштабирования, которые нельзя получить при установке кластера.

Репликация

Репликация, третья технология высокой отказоустойчивости SQL Server, сложна по структуре, но проста в использовании. Из-за сложности структуры ее стараются не использовать для целей высокой отказоустойчивости так часто, как перемещение журналов.

Переключение узлов кластера работает на уровне серверов, гарантируя, что SQL Server доступен целиком. Перемещение журналов работает на более тонком уровне, гарантируя отказоустойчивость одной базы данных в пределах сервера. Репликация соответствует самому мелкому уровню: она обеспечивает отказоустойчивость по транзакциям и может даже делать это лишь для части одной таблицы в базе данных. В отличие от перемещения журналов, восстанавливающего резервные копии журналов транзакций с первичного сервера на вторичном сервере, репликация работает с журналом транзакций и посылает индивидуальные транзакции на вторичный сервер по мере их поступления. Благодаря этой детализирующей функции репликация в состоянии обеспечить максимально быстрое переключение с первичного сервера на вторичный. В самых надежных конфигурациях можно хранить данные на вторичном сервере, с задержкой на 1-2 секунды от первичного.

Несмотря на то, что с помощью репликации можно достичь невероятно низкой задержки, она не имеет механизма запуска по расписанию, который требует максимальной задержки между первичным и вторичным серверами. Механизм репликации реплицирует данные и делает их доступными на вторичном сервере, как только они туда поступают. Хотя механизм репликации в конечном итоге доставит данные, неопределенное время доставки вызывает целый ряд проблем.

К счастью, время доставки полностью контролируется разработчиками, администраторами баз данных и другими IT-профессионалами. Репликация транзакции не происходит до тех пор, пока транзакция не подтверждена, поэтому разработчики, пишущие большие транзакции, создают проблемы задержки репликации на двух фронтах. Во-первых, поскольку эти долго выполняющиеся транзакции не реплицируются на вторичный сервер до тех пор, пока они не завершены, вторичный сервер значительно отстает от первичного. Во-вторых, когда транзакция подтверждена, упаковка транзакции, пересылка и исполнение ее на вторичном сервере занимают много времени. Дополнительно репликация транзакций гарантирует, что на вторичном сервере транзакции будут проводиться точно в таком же порядке, как на первичном. Поскольку механизм репликации преобразует в последовательную форму все проведенные транзакции, все последующие проведенные транзакции будут стоять в очереди позади большой транзакции, ожидая своей очереди на выполнение.

Это может показаться жестким ограничением и имеет значительные последствия для механизма репликации, но не слишком сильно ухудшает отказоустойчивость. При реализации репликации для целей отказоустойчивости обычно задействуют не меньше трех серверов. Publisher - это первичный сервер, где приложения пересылают все транзакции. Subscriber - вторичный сервер, который действует как двойник первичного, доступный в случае сбоя на первичном сервере. Единственная задача третьего сервера, Distributor, - гарантировать доставку транзакций на вторичный сервер. Как только транзакции копируются с Publisher на Distributor, Distributor доставляет их на Subscriber. Такая схема позволяет приложению немедленно переключаться на вторичный сервер, даже если, возможно, не все транзакции на вторичном сервере были проведены, поскольку Distributor гарантирует их доставку. Вообще, то, насколько хорошо вы управляетесь с этой задержкой в процессе обеспечения отказоустойчивости данных, определяет то, на! сколько быстро вы сможете переключиться в аварийной ситуации с первичного сервера на вторичный. В идеальных условиях кластеризация позволяет достичь аварийного переключения примерно за 15 секунд, перемещение журналов позволяет достичь переключения за время примерно от 1 до 2 минут, а репликация дает немедленное переключение.

Как и перемещение журналов, репликация может поддерживать столько вторичных серверов, сколько вы можете развернуть. Ограничение может исходить только от обрабатывающей способности систем, пропускной способности сети и возможностей по управлению инфраструктурой. Как и в случае с перемещением журналов, вторичный сервер можно использовать для того, чтобы "сбрасывать" на него операции чтения, обеспечивая тем самым дополнительную масштабируемость. Вторичный сервер остается на 100% доступным для операций чтения, даже когда Distributor работает с транзакциями. Он остается доступным потому, что, в отличие от восстановления транзакций по журналам, на котором основана технология перемещения журналов, и которое не может произойти, пока другой пользователь имеет доступ к базе данных, механизм репликации выполняет те же транзакции на вторичном сервере, по мере того как приложение выполняет их на первичном сервере. Кроме того, как и в случае перемещения журналов, у репликации! нет единой точки аппаратного сбоя, поскольку она использует физически отдельный сервер и предоставляет не автоматическую процедуру аварийного переключения. Побочным эффектом существенной переработки транзакций механизмом репликации на вторичном сервере является то, что механизм репликации не пропускает поврежденные данные с первичного сервера на вторичный. Заметьте, что, как и другие технологии высокой отказоустойчивости, репликация не защитит вас от ошибок пользователя. Это и есть та самая проблема высокой отказоустойчивости, с которой нельзя справиться посредством технологии.

Казалось бы, для высокой отказоустойчивости ничего лучше репликации и представить невозможно, но не все так просто. Несмотря на то, что аппаратное обеспечение разделено на компоненты физически, репликация связывает воедино несколько компьютеров, поэтому сбой на одном сервере может вызывать сбой на другом. Это называется программным сбоем, и обычно является следствием того, что журнал транзакций заполняет доступное дисковое пространство и база данных переходит в нерабочий режим. Обращение к резервной копии журнала транзакций проблему не решает, потому что хотя такая резервная копия удаляет проведенные транзакции из журнала, она не удаляет транзакции о реплицированных таблицах из журнала до тех пор, пока они не окажутся на следующем по цепочке сервере. Следовательно, реплицируемые транзакции на Publisher не могут быть удалены из журнала транзакций до тех пор, пока они не будут успешно записаны на Distributor. И нельзя удалить транзакции с Distributor до тех пор, пока они не будут записаны на все серверы Subscriber. Если на Subscriber происходит сбой, и сервер долго остается в нерабочем режиме, рост объема данных на сервере Distributor может привести к переполнению доступного дискового пространства, что вызовет переход сервера Distributor в нерабочий режим. Это, в свою очередь, препятствует удалению транзакций из журнала на Publisher, которое не происходит до тех пор, пока они не будут успешно записаны на Distributor. Если журнал транзакций переполняется и не может быть расширен, первичный сервер переходит в нерабочий режим. Если вы реализуете репликацию для высокой отказоустойчивости, необходимо тщательно отслеживать и быстро устранять сбои неаппаратного характера, чтобы предотвратить такие каскадные сбои.

Три способа достижения высокой отказоустойчивости

Для построения архитектур высокой отказоустойчивости можно использовать три главные технологии SQL Server 2000 и по отдельности, и все вместе. Переключение узлов кластера защищает от аппаратных сбоев и обеспечивает автоматический перезапуск SQL Server на работающем оборудовании. Но переключение узлов кластера имеет единую точку возможного сбоя в дисковом массиве с разделенным доступом, не может защитить от ошибок данных, не предоставляет никаких функций для масштабируемости и в высшей степени чувствительно к длительности транзакций. Перемещение журналов защищает от сбоев аппаратуры и может предотвратить некоторые сбои на уровне данных; оно также предоставляет элементарный механизм снятия нагрузки по подготовке отчетов с первичного сервера на вторичный и повышает масштабируемость системы. Но перемещение журналов также чувствительно к длительности транзакций и имеет недостаток, состоящий в необходимости поддерживать отдельную копию данных при отсутствии простого способа обратного переключения с вторичного сервера на первичный. Репликация может защитить от аппаратных сбоев и порчи данных SQL Server, обеспечивая при этом высокий уровень масштабируемости в любой среде. Но репликация не может защитить от ошибок пользователя, чувствительна к размеру и длительности транзакций и относительно сложна в реализации.

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

Восстановление после сбоя тоже означает отказоустойчивость

Цель высокой отказоустойчивости - создать систему, позволяющую информационным отделам минимизировать время простоев критически важных систем. Другими словами, высокая отказоустойчивость напрямую связана с людьми, подходами и технологиями, позволяющими быстро восстановить неисправный элемент и понести при этом минимальные потери. Отказоустойчивость измеряется в терминах времени простоя.

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

У IT-профессионалов, желающих иметь бюджет для реализации ресурсоемких планов по восстановлению после сбоя, выход один - учитывать восстановление после сбоя в рамках процессов достижения высокой отказоустойчивости. IT- специалисты должны понять, что инвестиции, сделанные в восстановление после сбоя, - это инвестиции в высокую отказоустойчивость, и наоборот.

2. РАЗРАБОТКА ПРИЛОЖЕНИЯ

2.1 Постановка задачи

Создать БД сотрудников для расчета заработной платы на примере расчетной ведомости унифицированной формы Т51 . Исходными данными, описывающими предметную область, является:

1) Таблица Должность. Состоит из следующих полей:

· Код должности;

· Название должности;

· Оклад.

2) Таблица Подразделение. Состоит из следующих полей:

· Код подразделения;

· Название подразделения.

3) Таблица Начисления. Состоит из следующих полей:

· Код начисления;

· Название начисления;

· Размер начисления.

4) Таблица Удержание. Состоит из следующих полей:

· Код удержания;

· Название удержания;

· Размер удержания.

5) Таблица Выплаты. Состоит из следующих полей:

· Код выплаты;

· Название выплаты;

· Размер выплаты.

6) Таблица Сотрудник. Состоит из следующих полей:

· Таб. Номер сотрудника;

· ФИО сотрудника;

· Год рождения;

· Ставка;

· Код должности;

· Код подразделения.

7) Таблица Ведомость. Состоит из следующих полей:

· Код ведомости;

· Таб. Номер сотрудника;

· Код должности;

· Код подразделения;

· Ставка;

· Код начисления;

· Код выплаты;

· Код удержания;

· Всего.

Приложение должно обеспечить работу с таблицами:

· Просмотр таблиц;

· Редактирование таблиц ( удаление или добавление записей и их корректировка, поиск);

· Представление результатов поиска.

Для разработки БД использовались система управления базами данных Microsoft SQL Server 2005 и среда визуального проектирования Borland Delphi 7.0.

база данные проектирование реляционный

2.2 Логическое проектирование АИС

2.2.1 Проектирование БД

Рис.4 Проектирование БД

2.2.2 Проектирование интерфейса

Для реализации БД в Borland Delphi 7.0. создаются формы:

1.Главная форма - На главной форме расположено меню, с помощью которого можно перейти к справочникам сотрудники, должности, подразделения, начисления, выплаты, удержания и к расчетной ведомости Т51.

2. Форма для вывода справочников и ведомости - на этой форме расположены справочники, которые отражают сведения о сотрудниках, должностях, подразделениях, начислениях, выплатах и удержаниях. Также на этой форме отображается таблица, которая выводит ведомость.

3. Форма для вывода информации о БД и ее разработчике.

4. Форма для вывода уточнения о выходе.

2.3 Физическая реализация

Реализация проекта осуществляется следующим образом:

1. В Microsoft SQL Server 2005 создаются таблицы:

1)Таблица Должность. Состоит из следующих полей:

· Код должности - int;

· Название должности - varchar(30);

· Оклад - money.

2)Таблица Подразделение. Состоит из следующих полей:

· Код подразделения - int;

· Название подразделения- varchar(30).

3)Таблица Начисления. Состоит из следующих полей:

· Код начисления - int;

· Название начисления- varchar(30);

· Размер начисления - money.

4)Таблица Удержание. Состоит из следующих полей:

· Код удержания - int;

· Название удержания- varchar(30);

· Размер удержания - money.

5)Таблица Выплаты. Состоит из следующих полей:

· Код выплаты - int;

· Название выплаты- varchar(30);

· Размер выплаты - money.

6) Таблица Сотрудник. Состоит из следующих полей:

· Таб. Номер сотрудника - int;

· ФИО сотрудника- varchar(30);

· Год рождения - int;

· Ставка - real;

· Код должности - int;

· Код подразделения - int.

7)Таблица Ведомость. Состоит из следующих полей:

· Код ведомости - int;

· Таб. Номер сотрудника - int;

· Код должности - int;

· Код подразделения - int;

· Ставка - int;

· Код начисления - int;

· Код выплаты - int;

· Код удержания- int;

· Всего - int.

Подробное описание каждого типа:

· INT - Хранит целые числа со знаком или без знака в диапазоне от -2 147 483 648 до 2 147 483 647. Занимает 4 байта. Все целочисленные типы данных, а также типы, хранящие десятичные дроби, поддерживают свойство

· MONEY -Хранит денежные значения в диапазоне от -922337203685477.5808 до 922337203685477.5807. Значение занимает 8 байт.

· REAL - Хранит значения с плавающей точкой в диапазоне -3.40Е+38 до 3.40Е+38. Занимает 4 байта. Тип REAL функционально эквивалентен типу FLOAT(24).

· VARCHAR (n) -Хранит символьные данные фиксированной длины размером от 1 до 8000 символов. Занимаемое место равно реальному размеру введенного значения в байтах, а не значению n.

2. Создаем схему БД

Рис. 5 схема БД

3. В Borland Delphi 7.0. создаем формы для размещения данных таблиц и запроса.

Для соединения с базой данных необходимо воспользоваться компонентом ADOConnection на вкладке ADO. Поместим такой компонент на форму. Далее выбираем свойство ConnectionString. Появляется окно - рис 7.

Рис. 7 Указывается путь к БД

Нажимаем кнопку Build, появляется окно - рис 8.

Рис. 8 Выбор поставщика

Выбираем поставщика и нажимаем кнопку далее.

В появившейся вкладке соединение выберем Имя сервера и базу данных на сервере. Имя пользователя и пароль не трогать.

Далее в вкладке ADO размещаем на форму компонент ADOTable - свойства:

1. connection - ADOConnection

2. TableName - указываем одну из таблиц БД(нажимаем на галочку, появляется список таблиц, выбрать любую из них).

В вкладке Data Access выбираем компонент Data Source, размещаем на форму. Свойство - DataSet - выбираем ADOTable.

В кладке Data Controls размещаем компонент DBGrid . Свойство - Data Source выбираем Data Source.

Далее необходимо вернуться в вкладку свойств для компонента ADOTable и установить свойство Active - true.

Таблица появляется в компоненте DBGrid.

Появляется окно :

Рис.9 Окно пароля

Наживаем кнопку ок

Результат



Рис.10 Результат

Для того, чтобы можно было добавлять, удалять и редактировать поля таблицы, надо разместить еще один компонент. Во вкладке Data Controls выбираем компонент DBNavigator. у него установить свойство - Data Sourse - Data Sourse.

В данной курсовой работе использовались след. компоненты:

Компонент TLabel

TLabel служит для отображения текста на экране. Можно изменить шрифт и цвет метки, если дважды щелкнуть на свойство Font в Инспекторе Объектов. Видно, что это легко сделать и во время выполнения программы, написав всего одну строчку кода.

Компонент TImage

TImage - отображает графическое изображение на форме. Воспринимает форматы BMP, ICO, WMF. Если картинку подключить во время дизайна программы, то она прикомпилируется к EXE файлу.

Компонент TButton

TButton позволяет выполнить какие-либо действия при нажатии кнопки во время выполнения программы. В Delphi все делается очень просто. Поместив TButton на форму, по двойному щелчку можно создать заготовку обработчика события нажатия кнопки. Далее нужно заполнить заготовку кодом. Этот компонент доступен из модуля STDCTRL, и находится на странице палитры компонентов Standard

Компонент TMainMenu

Компонент TMainMenu предназначен для добавления к программе главного меню.

Компонент TMainMenu - невизуальный, в отличие от визуальных компонентов TEdit и TLabel, в точности соответствующих своему внешнему виду в работающей программе. Это означает, что хотя он виден на форме как небольшой квадрат, в окне созданной программы в таком виде компонент не появится.

Компонент TDataSource

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

Все наборы данных должны быть связаны с компонентом источника данных, если требуется редактирование данных. Основное свойство источника данных - DataSet. Оно указывает на компонент набора данных (Table, Query и др), с которыми связан источник.

Свойство	Описание
DataSet	Набор данных, с которым связан компонент.

Компонент ADOConnection

Компонент ADOConnection обеспечивает соединение с базой данных.

Свойство	Описание
ConnectionString	Строка соединения. Содержит информацию, необходимую для подключения к базе данных.

Компонент DBGrid

Компонент DBGrid используется для просмотра и редактирования базы данных в режиме таблицы.

Таблица

Свойства	Описание
DataSource	Источник отображаемых в таблице данных [компонент DataSource].

Компонент ТADOTable

Компонент ТАDOTаblе обеспечивает использование в приложениях Delphi таблиц БД, подключенных через провайдеры OLE DB. По своим функциональным возможностям и применению он подобен стандартному табличному компоненту.

Соединение с базой данных осуществляется установкой в свойства Active значения true. При этом если связь с базой данных осуществляется через компонент ADOConnection, надо учитывать указанную в описании этого компонента взаимосвязь свойства Active компонента ТADOTable и свойства Connected компонента ADOConnection.

2.4 Инструкция для пользователя

Для запуска программы необходимо выбрать файл BazaDannihKino.exe.

Появляется окно приветствия, рисунок 11.

Для того, чтобы просмотреть данные о сотрудниках, необходимо в пункте меню «Сотрудники» выбрать «Просмотреть всех», после чего данные появятся на экране. Для того чтобы добавить нового сотрудника или удалить старого, необходимо в пункте меню «Сотрудники» выбрать «Добавить/удалить», после чего все данные появятся на экране, а также появиться навигатор, с помощью которого вы сможете добавлять или удалять записи, рисунок 12.

Можно просмотреть справочники «Начисления», рисунок 13, «Удержания», рисунок 14, «Выплаты», рисунок 15, с помощью пункта меню «Бухгалтерский учет».

Также, с помощью пункта меню «Справочники» можно просмотреть такие справочники, как «Должности», рисунок 16, и «Подразделения», рисунок 17.

Для того чтобы просмотреть Расчетную ведомость, унифицированную форму Т-51., необходимо выбрать пункт меню Расчетная ведомость, после чего данная таблица появиться на экране, рисунок 18. Для того чтобы выгрузить данную ведомость в Excel, необходимо в меню Действия выбрать пункт меню Выгрузка файла в Excel,после чего данная ведомость выгрузить. Также Вы можете распечатать ведомость, выбрав пункт меню Печать в меню Действия. Закрыть ведомость можно с помощью пункта меню Закрыть в меню Действия.

С помощью пункта меню «О программе» можно просмотреть данные о самой базе данных и его разработчике, рисунок 19.

Для получения помощи по работе с программой необходимо выбрать пункт меню «Справка», после чего появиться справка, рисунок 20.

Закрыть программу возможно в любой момент. Для этого надо нажать на пункт меню «Выход». После чего подтвердить выбор, нажав кнопку Да, рисунок 21.

ЗАКЛЮЧЕНИЕ

Цель курсовой работы достигнута. При выполнении курсовой работы в СУБД SQL Server были созданы таблицы, а в среде визуального проектирования Borland Delhi происходит их реализация, а также создание запросов.

Разработанное приложение является работоспособным, эффективно работающим с данными. Обеспечивая с одной стороны выполнение всех необходимых для данной предметной области операций над данными, не предъявляет высоких требований к аппаратным ресурсам компьютера.

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

При написании данного приложения были использованы знания, полученные в результате изучения дисциплин: базы данных, алгоритмические языки высокого уровня и информационные системы, так как для представления программ в Delphi используется язык Object Pascal, в основе которого лежит ставший классическим Turbo Pascal. В данной работе были широко использованы методы работы с БД и СУБД, создание таблиц, организация связи между ними и другое.

Достоинством этой программы является:

удобный пользовательский интерфейс;

наглядность таблиц;

возможность печати и выгрузки ведомости;

возможность корректировать данные;

возможность просмотра ведомости.

Для дальнейшего усовершенствования данного программного продукта можно добавить:

усовершенствовать запрос;

добавить дополнительные поля в таблицы;

увеличить количество операций СУБД;

Таким образом, база данных легко поддаётся алгоритмизации в силу достаточно простых процедур, хотя это не является очевидным. Все эти недостатки, при необходимости, устранить, возможно, и при этом за небольшой промежуток времени. Системные требования: P 166/32 Mb/Ос Win9x.

СПИСОК ЛИТЕРАТУРЫ

1. Бобровский С. Delphi5: учебный курс. - Спб: Питер, 2001, - 640 с;

2. Фаронов В. Программирование баз данных в Delpi 7: учебный курс. - Спб: Питер, 2003, 459 с;

3. Хомоненко А., Цыганков В., Мальцев М. Базы данных: учебное пособие. - Спб: Корона, 2003, - 665 с.

Приложение

Листинг программы

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Grids, DBGrids, DB, ADODB, ExtCtrls, DBCtrls, StdCtrls, Menus,

jpeg, MPlayer;

type

TForm1 = class(TForm)

ADOConnection1: TADOConnection;

ADOTable1: TADOTable;

DataSource1: TDataSource;

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

Label1: TLabel;

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

Image1: TImage;

N7: TMenuItem;

MediaPlayer1: TMediaPlayer;

procedure N5Click(Sender: TObject);

procedure N6Click(Sender: TObject);

procedure N2Click(Sender: TObject);

procedure N3Click(Sender: TObject);

procedure N4Click(Sender: TObject);

procedure N7Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses Unit2,Unit3;

{$R *.dfm}

procedure TForm1.N5Click(Sender: TObject);

begin

aboutbox.show

end;

procedure TForm1.N6Click(Sender: TObject);

begin

Form1.Close

end;

procedure TForm1.N2Click(Sender: TObject);

begin

form3.Show;

With Form3 do

begin

DBGrid2.Visible:= False;

DBGrid3.Visible:= False;

Label2.Visible:=False ;

Label3.Visible:=False ;

DBGrid4.Visible:= False;

Label4.Visible:=False ;

DBNavigator2.Visible:=False;

DBNavigator3.Visible:=False;

DBNavigator4.Visible:=False;

DBGrid1.Visible:= true;

Label1.Visible:=true ;

DBNavigator1.Visible:=true;

end;

end;

procedure TForm1.N3Click(Sender: TObject);

begin

form3.Show;

With Form3 do

begin

DBGrid1.Visible:= False;

DBGrid3.Visible:= False;

Label1.Visible:=False ;

Label3.Visible:=False ;

DBGrid4.Visible:= False;

Label4.Visible:=False ;

DBNavigator1.Visible:=False;

DBNavigator3.Visible:=False;

DBNavigator4.Visible:=False;

DBGrid2.Visible:= true;

Label2.Visible:=true ;

DBNavigator2.Visible:=true;

end;

end;

procedure TForm1.N4Click(Sender: TObject);

begin

form3.Show;

With Form3 do

begin

DBGrid2.Visible:= False;

DBGrid1.Visible:= False;

Label2.Visible:=False ;

Label1.Visible:=False ;

DBGrid4.Visible:= False;

Label4.Visible:=False ;

DBNavigator2.Visible:=False;

DBNavigator1.Visible:=False;

DBNavigator4.Visible:=False;

DBGrid3.Visible:= true;

Label3.Visible:=true ;

DBNavigator3.Visible:=true;

end;

end;

procedure TForm1.N7Click(Sender: TObject);

begin

form3.Show;

With Form3 do

begin

DBGrid2.Visible:= False;

DBGrid3.Visible:= False;

Label2.Visible:=False ;

Label3.Visible:=False ;

DBGrid1.Visible:= False;

Label1.Visible:=False ;

DBNavigator2.Visible:=False;

DBNavigator3.Visible:=False;

DBNavigator1.Visible:=False;

DBGrid4.Visible:= true;

Label4.Visible:=true ;

DBNavigator4.Visible:=true;

end;

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

MediaPlayer1.FileName := 'H:\МИСиС\ИС\Курсовая работа\Film_film_film.mp3' ;

MediaPlayer1.Open;

MediaPlayer1.Play;

end;

end.

unit Unit2;

interface

uses Windows, SysUtils, Classes, Graphics, Forms, Controls, StdCtrls,

Buttons, ExtCtrls, jpeg;

type

TAboutBox = class(TForm)

Panel1: TPanel;

ProgramIcon: TImage;

ProductName: TLabel;

Version: TLabel;

Copyright: TLabel;

Comments: TLabel;

OKButton: TButton;

procedure OKButtonClick(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

AboutBox: TAboutBox;

implementation

{$R *.dfm}

procedure TAboutBox.OKButtonClick(Sender: TObject);

begin

AboutBox.Close

end;

end.

unit Unit3;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, jpeg, ExtCtrls, StdCtrls, DBCtrls, Grids, DBGrids, DB, ADODB;

type

TForm3 = class(TForm)

ADOTable1: TADOTable;

ADOTable2: TADOTable;

ADOTable3: TADOTable;

DataSource1: TDataSource;

DataSource2: TDataSource;

DataSource3: TDataSource;

ADOConnection1: TADOConnection;

DBGrid1: TDBGrid;

DBGrid2: TDBGrid;

DBGrid3: TDBGrid;

DBNavigator1: TDBNavigator;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Image1: TImage;

DBNavigator2: TDBNavigator;

DBNavigator3: TDBNavigator;

ADOTable4: TADOTable;

DataSource4: TDataSource;

DBGrid4: TDBGrid;

DBNavigator4: TDBNavigator;

Label4: TLabel;

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form3: TForm3;

implementation

uses Unit1;

{$R *.dfm}

end.

Размещено на Allbest.ru