Принципы разработки и эксплуатации систем управления удаленными базами данных

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

Введение

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

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

Использование Internet/Intranet технологий при создании информационных ресурсов и построении информационных систем различного назначения в последнее время стало доминирующим в мировом информационном пространстве по следующим причинам. Эти технологии:

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

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

Поддерживают распределенные системы хранения информации и множественные методы ее хранения.

Поддерживают работу с практически неограниченным объемом разноплановых данных (текст, графика, изображение, звук, видео, векторные карты и др.).

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

Поддерживают удаленные методы редактирования и пополнения информации.

Целью моей курсовой работы является изучение и анализ информации по теме курсовой работы «Принципы разработки и эксплуатации систем управления удаленными базами данных» и разработка базы данных «Спортивный клуб» для приобретения навыков по созданию баз данных.

В связи с этим были поставлены следующие задачи:

закрепить и расширить теоретические знания в области удаленных баз данных;

приобрести расширенные знания по использованию возможностей Microsoft Access;

выработать умение формулировать выводы и затем последовательно их излагать;

выработать умение публичной защиты.

Объектом исследования курсовой работы является система управления удаленными базами данных.

Предметом исследования являются принципы разработки и эксплуатации систем управления удаленными базами данных. Так же предметом исследования данной курсовой работы является «Спортивный клуб». Объектом исследования является организация занятий посетителей в этом клубе.

Глава 1. Принципы разработки и эксплуатации систем управления удаленными базами данных

1.1 Основные понятия удаленных баз данных

удаленный база данных управление

СУБД - программа, либо комплекс программ, предназначенных для полнофункциональной работы с данными. Как правило, включает в себя инструменты для создания и изменения структуры хранения наборов данных, а также средства доступа к хранимым данным, с возможностью их чтения, добавления, изменения и удаления. При этом, у большинства СУБД имеется собственный встроенный для работы с данными. Сама база данных обычно находится просто в файлах закрытого, либо открытого формата. [10]

Пользователь БД - это программа или человек, обращающиеся к БД на языке манипулирования данными. [10]

Запрос - это процесс обращения пользователя к БД с целью ввода, получения или изменения информации в БД. [10]

Логическая структура БД - это определение БД на физически независимом уровне, ближе всего соответствующем концептуальной модели БД. [14]

Топология БД - это схема распределения физических БД по сети. Локальная автономность означает принадлежность локальному владельцу информации локальной БД и связанных с ней определенных данных. [14]

Удаленный запрос - это запрос, который выполняется с использованием модемной связи. [14]

Транзакция - это последовательность операций модификации данных в БД, переводящая БД из одного непротиворечивого состояния в другое непротиворечивое состояние.[14]

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

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

SQL-сервер - сервер для управления реляционными БД обычно называют SQL-сервером. SQL (Structured Query Language -- язык структурированных запросов) является стандартным языком для работы с реляционными БД. Кроме стандартных реляционных операций, этот язык предоставляет возможности для изменений структуры таблиц. Различные варианты SQL используются во всех, как серверных, так и в настольных реляционных СУБД.

SQL является стандартным языком для работы с реляционными БД. Разделяется на две основные части: DDL (Data Definition Language -- язык определения данных) и DML (Data Manipulation Language -- язык обработки данных). DDL предоставляет средства для создания и изменения структуры хранения данных. DML предназначен для чтения и изменения данных. Основные операторы DML: select -- выборка, insert -- вставка, update -- изменение, delete -- удаление. Также, с помощью SQL, часто реализован доступ к служебным функциям SQL-сервера. [13]

1.2 Основные тенденции развития средств удаленного управления

Удаленный доступ - широкое понятие, которое включает в себя различные типы и варианты взаимодействия компьютеров, сетей и приложений. Существует огромное количество схем взаимодействия, которые можно назвать удаленным доступом, но их объединяет использование глобальных каналов или глобальных сетей при взаимодействии. Кроме того, для удаленного доступа, как правило, характерна несимметричность взаимодействия, то есть, с одной стороны, имеется центральная крупная сеть или центральный компьютер, а с другой - отдельный удаленный терминал, компьютер или небольшая сеть, которые должны получить доступ к информационным ресурсам центральной сети. За последние год-два количество предприятий, имеющих территориально распределенные корпоративные сети, значительно возросло. [11]

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

Отличия между удаленным узлом и удаленным управлением:

Удаленное управление

ПО удаленного управления используется уже несколько лет. Оно дает пользователям или администратору возможность управлять удаленной машиной и выполнять разнообразные функции. При использовании удаленного управления, от удаленной машины на локальную машину посылаются коды нажатых клавиш. Локальная машина посылает на удаленную изменения экрана. Обработка и передача файлов делаются на локальной машине. [13]

Преимущества удаленного управления

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

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

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

Недостатки удаленного управления

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

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

Последний недостаток удаленного управления состоит в том, что скорость передачи файлов между локальным и удаленным ПК ограничена скоростью соединения. [13]

Удаленный доступ (узел)

Удаленный ПК, оборудованный модемом или сетевой платой, выполняет соединение через глобальную сеть к локальному серверу. Этот удаленный ПК теперь рассматривается как локальный узел сети, способный получать доступ к сетевым ресурсам, например, к другим ПК. Сервер отвечает за предоставление всей сетевой информации, за передачу файлов, и даже за некоторые приложения на удаленном узле. [13]

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

Из-за этих ограничений вычисления на удаленном узле предъявляют высокие требования к пропускной способности канала связи. Это следует учитывать при проектировании. Между клиентом на локальном ПК и клиентом удаленного узла есть небольшое различие. Сервер будет одинаково обрабатывать запросы от любой машины. Но если локальный клиент запрашивает 2Мб данных, сервер передаст их по локальной сети. Для удаленного клиента, по каналу 56Кб эта передача займет около 6 минут. Кроме того, после внесения изменений клиент должен отправить эти 2Мб обратно.

Преимущества вычисления на удаленном узле

Для начинающих удаленный доступ проще настроить. Все, что требуется - это подключиться к серверу. Для этого обычно используется RAS или соединение через Интернет.

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

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

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

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

Недостатки вычисления на удаленном узле

Скорость является ключевым аспектом, поскольку передается намного больше данных, чем при удаленном управлении.

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

Последнее замечание по поводу удаленного доступа касается совместимости аппаратных платформ. Заранее не зная конфигурации ПК клиента, часто приходится строго ограничивать список поддерживаемых конфигураций. Это часто ограничивает пользователя. [9]

1.3 CALS-технологии - основная концепция разработки удаленных баз данных

CALS-технологии - это современное направление развития информационного обеспечения производственных и бизнес-процессов, направленное на создание единого информационного пространства, основу которого составляют удаленные интегрированные базы данных. [11]

Концепция и идеология CALS зародилась в недрах военно-промышленного комплекса США, а затем была принята всеми странами НАТО.

В России принят адекватный аналог CALS - информационная поддержка жизненного цикла изделий (ИПИ).

Суть ИПИ. В соответствии со схемой основу ИПИ составляет и интегрированная информационная среда (ИИС), или единое и формационное пространство (ЕИП). Эти термины равнозначны, однако в терминологическом словаре, утвержденном ГОСТом России, принят первый термин - ИИС. [11]

Некоторые компоненты формирования общей базы данных промышленного предприятия.

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

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

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

системы автоматизированного конструкторского и технологического проектирования (CAE/CAD/CAM);

программные средства управления данными об изделиях, в том числе СУБД (PDM);

автоматизированные системы планирования и управления производством (MRP/ERP);

системы анализа, поддержки и ведения баз данных (LSA/ LSAR);

программные средства управления потоками работ (WF);

программные средства моделирования и анализа бизнес-процессов (SADT). [12]

Как видно из перечисленных задач и применяемых для их реализации программных систем, основой для создания ИИС являются базы данных.

Исходя из концепции CALS-технологий, традиционное проектирование базы данных, как самостоятельного объекта, необходимо существенным образом изменить и перейти к стратегии создания многопользовательских общих баз данных.

1.4 Принципы разработки многопользовательских информационных систем

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

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

системный подход;

стандартизация.

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

При проектировании информационных систем необходимо:

учитывать интересы всех потенциальных пользователей системы;

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

использовать принцип учета интересов всех потенциальных пользователей системы.

Принцип учета интересов всех потенциальных пользователей системы определяет следующий порядок разработки БД:

1. Установить, каким специалистам и в каких подразделения предприятия необходима информация о конкретном информационном объекте.

2. Установить признаки описания объектов различными пользователями.

3. Установить общий состав признаков объектов одного класса.

По мнению Диго С.М., такой подход к проектированию увеличивает сроки разработки БД, но обеспечивает значительное снижение затрат на разработку всей системы в целом. [1]

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

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

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

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

Стандартизация разработки информационных систем, включает в себя следующие аспекты:

информационный;

программный;

аппаратный.

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

Применительно к текстовой информации этот аспект разработки БД означает, что четкие правила идентификации (грамматические правила написания) должны быть установлены для всех информационных объектов. Так, установив название инструмента для механической обработки детали резец расточной, недопустимо использовать никакой другой способ его обозначения, т.е. название «расточной резец» не идентично названию «резец расточной». [1]

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

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

Внедрение в настоящее время на предприятиях России концепции CALS-технологий предусматривает широкое применение единых, в том числе и международных, стандартов. [1]

1.5 Организация многопользовательских систем управления базами данных в локальных вычислительных сетях

Компьютерные информационные системы современных предприятий разрабатываются с применением сетевых технологий, т.е. компьютеры объединяют в локальные вычислительные сети. При разработке баз данных в ЛВС предприятий применяют два типа (две архитектуры) их организации: файл-сервер и клиент-сервер. [8]

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

Отличаются эти две архитектуры организации баз данных способами обработки информации.

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

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

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

Недостатки организации БД по архитектуре файл-сервер:

при передаче по сети файлов БД (особенно с большими потоками информации и с учетом возможного обращения к файлу одновременно нескольких пользователей) резко снижается производительность работы с системой;

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

Преимущества организации БД по архитектуре клиент-сервер:

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

централизованное хранение и обработка данных на сервере повышает надежность работы системы;

разработку серверной части СУБД можно выполнять на языке SQL или на других языках высокого уровня, что повышает надежность и производительность обработки данных. Разработку клиентской части СУБД можно выполнять с применением программных продуктов, например Visual Basic и MS Access, что значительно сокращает время разработки информационной системы. [7]

1.6 Этапы проектирования многопользовательских УБД

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

Такой переход предусматривает необходимость разработки СУБД данных в соответствии с этапами их жизненного цикла.

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

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

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

определить цель и задачи информационных технологий основе анализа целей и бизнес-планов организации;

провести анализ существующих (в том числе действующих предприятии) информационных систем и дать рекомендации их применению или модернизации;

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

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

2. Определение требований к СУБД зависит от области применения баз данных, состава пользователей, а следовательно, и от назначения системы.

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

определение классов информационных объектов, их характеристик и, в конечном счете, состава таблиц баз данных;

определение места нахождения потенциальных пользователей и, в конечном счете, архитектуры ЛВС.

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

1. Одним - дать право модифицировать таблицы баз данных;

2. Другим - разрешить только доступ к информации без права ее изменения.

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

Существуют разные методы сбора информации, которые, в общем, определяются как методы сбора фактов. К этим методам относятся:

изучение документации;

проведение собеседований;

наблюдение за работой сотрудников подразделений предприятия;

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

проведение анкетирования.

Изучение документации, т.е. определение характеристик информационных объектов на основе технической документации, в соответствии с которой выполняет свои функции конкретный пользователь (подразделение) предприятия. [12]

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

Наблюдение за работой сотрудников подразделений предприятия относится также к эффективной методике сбора фактов. Данная методика позволяет:

убедиться в правильности установленных ранее характеристик информационных объектов;

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

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

Проведение анкетирования - метод, основанный на проведении опросов пользователей по заранее составленным опрос листам - анкетам. При этом возможны две формы опросных листов: произвольная и фиксированная. В первом случае опрос листы состоит из вопросов, на которые опрашиваемый должен дать ответ в произвольной форме. Во втором, опрашиваемому предоставляется бланк с вариантам, заранее сформулированных ответов на поставленные вопросы, из которых следует сделать выбор. [12]

К данному методу можно также отнести непосредственное «структурирование» таблицы базы данных для задач, выполняемых конкретным специалистом. В этом случае анкетирование можно выглядеть в виде собеседования или предоставить специалисту, самостоятельно составить структуру таблицы (или таблиц) базы данных, для чего целесообразно использовать конструктор таблиц СУБД Microsoft Access.

4. Разработка и исследование моделей проекта СУБД сводится к разработке и исследованию концептуальных, логических и физических моделей баз данных.

Концептуальное моделирование - это процесс создания информационной модели (базы данных), не зависящей от ее физической реализации. В общем случае это определение необходимо для состава таблиц базы данных исходя из установленного с пользователей. [12]

Логическое моделирование предполагает разработку и установление связей между таблицами базы данных, а также их модификацию на основе принципов нормализации. При разработке логической модели учитывается конкретная СУБД.

Физическое моделирование - это описание способов хранения базы данных на запоминающих устройствах. [12]

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

Физическое моделирование подразумевает:

определение конкретных структур хранения информации и методов доступа к удаленным таблицам баз данных;

выбор аппаратных, программных (технологических) и разработку организационных методов защиты данных. [12]

Схема моделирования проекта СУБД, которая отражает трехуровневую архитектуру построения и управления базами данных применяется в таких СУБД, как ORACLE и SQL Server. При такой схеме проектирования удаленных баз данных обеспечивается высокая степень независимости системы управления от данных.

Различают два типа независимости:

логическую;

физическую.

Логическая независимость от данных означает полную защищенность внешних схем от изменений, вносимых в концептуальную модель.

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

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

Внутренняя схема данных (или внутренний уровень) описывает способы хранения данных.

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

при разработке баз данных в конкретной предметной области;

интеграции с уже имеющимися на предприятии базами данных;

обращение к удаленным базам данных;

обеспечение защиты данных.

Набольшее распространение среди пользователей и разработчиков СУБД получили следующие программные продукты:

специальные языки программирования - Visual FoxPro, SQ;

прикладные программные системы (ППП) - Microsoft Access;

программные системы разработки и управления удаленными базами данных - Oracle, MS SQL-Serves, MYSQL, INFORMIX и др.

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

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

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

Разработка приложения управляющего работой баз данных состоит из создания двух программных частей:

серверной;

клиентской.

Серверная часть приложения разрабатывается, как правило, средствами встроенного в соответствующие СУБД языка SQL l Server, Oracle, и др.

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

Одним из средств разработки клиентской части приложения выполняется объектно-ориентированный язык программирования Visual Basic.NET. Эта современная визуальная среда обеспечивает:

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

возможность работы с Web-сервисами;

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

поддержку многоплатформенного протокола передачи данных - SOAP-протокола. [7]

SOAP-протокол - это набор правил для работы с удаленными объектами. Где именно находятся эти удаленные объекты (в другом каталоге, в корпоративной интрасети или в сети Интернет) - для клиентских программ, использующих SOAP-протокол, абсолютно неважно. [9]

SOAP-протокол основывается на языке ХМL. Любая передаваемая информация между клиентом и сервером в этом случае является отдельным XML-документом, написанным по правилам SOAP-протокола.

SOAP-протокол - это слабосвязанный механизм, ориентированный на сообщения и предназначенный для удаленного вызова объектов по глобальным сетям, работа с удаленными базами данных в котором осуществляется с помощью HTTP-запросов и ответов.

8. Реализация СУБД - это этап, следующий после разработки «эскизного проекта» и приложения. На этапе реализации информационной системы фактически осуществляется формирование базы данных в конкретных условиях производства, т. е. происходят:

формирование серверной части системы;

формирование клиентской части системы;

доработка программных модулей управления базой данных;

установление прав доступа к таблицам баз данных и разработка других методов защиты информации;

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

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

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

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

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

1. Непосредственной проверкой функционирования системы пользователями и администраторами в соответствии с разработанными инструкциями.

2. С помощью специальных экспертных программ, позволяющих автоматически находить ошибки, например при вводе данных в таблицы или запросы.

Эксплуатация и сопровождение - это этап, на котором полагается непрерывное наблюдение за разработанной системой в процессе ее функционирования. Контроль качества работы системы осуществляет администратор базы данных. Процесс контроля качества системы должен полностью соответствовать действующим на предприятии методам, системы менеджмента качеством, отвечающим требованиям стандартов ISO 1900:2000. [6]

1.7 Администрирование удаленных баз данных

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

В практике разработки и управления базами данных есть две функции:

администрирование данных;

администрирование баз данных.

Соответственно предусматривают и две должности:

администратор данных;

администратор баз данных.

Администрирование данных подразумевает управление информационными ресурсами, разработку и внедрение стандартное информационное обеспечение, концептуальное и логическое проектирование баз данных.

Перечень задач, возлагаемых на администратора данных:

выбор рациональных инструментальных средств разработки баз данных;

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

экспертная оценка осуществимости проектов и планирование процесса создания базы данных;

участие в разработке корпоративной модели данных;

определение требований организации к используемым данным и разработка словаря данных;

участие в разработке методик сбора данных и выбор фор их представления;

оценка существующих и ожидаемых объемов данных;

определение правил доступа к данным и мер безопасности, соответствующих правовым нормам и внутренним требованиям организации;

концептуальное и логическое проектирование базы данных;

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

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

взаимодействие со службами системы управления качеством в части анализа причин нарушения целостности БД или потери информации;

разработка и выбор методов и средств эффективной защиты, данных в условиях конкретного предприятия. [15]

Администрирование баз данных подразумевает управление физической реализацией разработанной информационной системы.

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

Приведем перечень задач администратора баз данных:

участие в оценке и выборе целевой СУБД на этапах проектирования баз данных;

физическое проектирование базы данных;

реализация физического проекта базы данных в среде целевой СУБД;

определение и реализация требований по защите и поддержке целостности данных;

взаимодействие с разработчиками приложений баз данных;

разработка стратегии тестирования баз данных;

обучение пользователей при работе с базами данных в ЛВС предприятия;

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

регулярное резервное копирование;

разработка требуемых механизмов и процедур восстановления информации в базах данных;

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

поддержка и обеспечение работоспособности используемого программного и аппаратного обеспечения. [15]

Базы данных часто создаются специализированными проектными коллективами на основе договора на разработку информационной системы в целом или базой данных как самостоятельного объекта проектирования. В этом случае служба администрации базы данных должна создаваться как в организации-разработчике, так и в организации-заказчике. [4]

На эффективность работы базы данных оказывают влияние множество внешних и внутренних факторов. Возрастание сложности и масштабов базы данных, высокая «цена» неправильных или запоздалых решений по администрированию БД, высокие требования к квалификации специалистов делают актуальной задачу использования развитых средствах автоматизированного (или даже автоматического) администрирования базы данных. [6]

Средства администрирования включены в состав всех СУБД. Особенно развиты эти средства в корпоративных СУБД.

Глава 2. Проектирование реляционной базы данных «Спортивный клуб»

2.1 Исследование предметной области

Целью проектирования базы данных «Спортивный клуб» является поддержание структурированной обработки данных о тренерах и клиентах.

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

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

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

Сбор и хранение данных (сведения о клиентах, тренерах, занятиях ).

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

Организация занятий посетителей.

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

Требования к базе данных:

получение из базы данных всей необходимой информации оперативно, в полном объеме и в форме, удобной для анализа;

информация должна быть абсолютно достоверной и соответствующей состоянию дел на текущий момент;

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

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

2.2 Проектирование базы данных «Спортивный клуб» методом нормальных форм

Перечень атрибутов

Атрибут	Тип атрибута	Формат атрибута
Код клиента	Числовой	Длинное целое
ФИО клиента	Текстовый	Длинное целое
Дата рожд. клиента	Дата/время	Краткий формат даты
Телефон клиента	Текстовый	10
Начало действия абонемента	Дата/время	Краткий формат даты
Конец действия абонемента	Дата/время	Краткий формат даты
Оплата	Денежный	Денежный
Отметка об оплате	Логический	Вкл/выкл
Код тренера	Текстовый	4
ФИО тренера	Текстовый	100
Адрес тренера	Текстовый	50
Телефон тренера	Текстовый	10
Дата рожд. тренера	Дата/время	Краткий формат даты
Серия, № паспорта	Текстовый	15
Стаж работы, лет	Текстовый	15
Оклад	Денежный	Денежный
Код вида занятия	Числовой	Длинное целое
Вид занятия	Текстовый	25
№ дня недели	Числовой	Длинное целое
День недели	Текстовый	15
Время	Текстовый	25
Продолжительность, мин.	Числовой	Длинное целое
№ зала	Числовой	Длинное целое
Наименование зала	Текстовый	25
Количество занятий	Числовой	25

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

Зависимости между атрибутами отношений:

Нормализация отношения.

Нормализация - процесс разбиения (декомпозиции) отношений с неудовлетворительными свойствами на новые отношения.

Первая нормальная форма. Отношение находится в первой нормальной форме, если все его атрибуты являются простыми (имеют единственное значение). Исходное отношение строится таким образом, чтобы оно находилось в 1НФ.

Сущность Тренеры (*Код тренера; *ФИО тренера; Адрес тренера; Телефон тренера; Дата рожд. тренера; Серия, № паспорта; Стаж работы, лет; Оклад; *Код вида занятия; Вид занятия; *№ дня недели; День недели; Время; Продолжительность, мин.; *№ зала; Наименование зала; Количество занятий; *Код клиента; ФИО клиента; Дата рожд. клиента; Телефон клиента; Начало действия абонемента; Конец действия абонемента; Оплата; Отметка об оплате).

Исходное отношение имеет составной ключ Код клиента, Код тренера, ФИО тренера, № дня недели, № зала, Код вида занятия. В этом отношении имеется явное и неявное избыточное дублирование данных. Часть избыточности устраняется при переводе отношения в 2НФ.

Вторая нормальная форма. Отношение находится в 2НФ, если:

1) отношение находится в 1НФ,

2) каждый не ключевой атрибут функционально полно зависит от первичного ключа (составного).

Или 2) любое неключевое поле должно однозначно идентифицироваться ключевыми полями.

Для перевода отношения в 2НФ используется операция проекции, то есть разложения отношения на несколько отношений.

Так как в моем отношении нет составного ключа, то оно уже находится в 3НФ.

Третья нормальная форма.

Отношение находится в 3НФ, если:

1) отношение находится в 2НФ,

2) каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

Или

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

Транзитивные зависимости приводят к избыточному дублированию информации в отношении, которое можно устранить операцией проекции на атрибуты, которые являются причиной транзитивных зависимостей. Преобразуем данное отношение в R1, R2, R3, R4, R5, R6, R7, R8, R9, каждое из которых находится в 3НФ:

Выделим R1 (сущность Клиенты):

(*Код клиента; ФИО клиента; Дата рожд. клиента; Телефон клиента; Код тренера).

Данное отношение имеет ключ Код клиента.

Выявим зависимости:

Код клиента Начало действия абонемента

Код клиента Конец действия абонемента

Код клиента Оплата

Код клиента Отметка об оплате

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

Так как все атрибуты функционально зависят от Кода клиента, выявим R2 (сущность Учет):

(*Код клиента; *Начало действия абонемента; Конец действия абонемента; Оплата; Отметка об оплате).

Данное отношение имеет составной ключ Код клиента, Начало действия абонемента.

Выявим транзитивную зависимость:

Код клиента ОплатаКоличество занятий

Код клиента Количество занятий

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

Так как атрибуты транзитивно зависят от Кода клиента, выявим R3 (сущность Количество занятий):

(*Оплата; Количество занятий).

Данное отношение имеет ключ Оплата. Выделим R4 (сущность Тренеры):

(*Код тренера; ФИО тренера; Адрес тренера; Телефон тренера; Дата рожд. тренера; Серия, № паспорта; Стаж работы, лет).

Данное отношение имеет ключ Код тренера.

Выявим зависимости:

Код тренера Стаж работы, лет

Стаж работы, лет Оклад

Код тренера Оклад

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

Так как между атрибутами имеются функциональные зависимости и взаимозависимости, выявим R5 (сущность Оклад):

(*Стаж работы, лет; Оклад)

Данное отношение имеет ключ Стаж работы, лет.

Выявим зависимости:

Код тренера Код вида занятия

Код тренера № дня недели

Код тренера № зала

Код тренера Время

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

Код тренера Продолжительность, мин

Так как все атрибуты функционально зависят от Кода тренера, выделим: R6 (сущность Залы):

(*Код тренера; Код вида занятия; Вид занятия; *№ дня недели; День недели; Время; Продолжительность, мин.; № зала; Наименование зала).

Данное отношение имеет составной ключ Код тренера, № дня недели.

Выявим зависимости:

Код тренера Код вида занятия Вид занятия

Код тренера Вид занятия

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

Так как имеет место транзитивная зависимость атрибутов от Кода тренера, выявим R7 (сущность Виды занятий):

(*Код вида занятия; Вид занятия).

Данное отношение имеет ключ Код вида занятия.

Выявим зависимости:

Код тренера № дня недели День недели

Код тренера День недели

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

Так как имеет место транзитивная зависимость атрибутов от Кода тренера, выявим R8 (сущность Дни недели):

(*№ дня недели; День недели).

Данное отношение имеет ключ № дня недели.

Выявим зависимости:

Код тренера № зала Наименование

Код тренера Наименование

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

Так как имеет место транзитивная зависимость атрибутов от Кода тренера, выявим R9 (сущность Залы):

(*№ зала; Наименование).

Данное отношение имеет ключ № зала.

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

Усиленная 3НФ или нормальная форма Бойса-Кодда (БКНФ).

Отношение находится в БКНФ, если оно находится в 3НФ и в нем отсутствуют зависимости ключей от неключевых атрибутов.

У нас подобной зависимости нет, поэтому процесс проектирования на этом заканчивается. Результатом проектирования является БД, состоящая из следующих таблиц: R3, R4, R5, R6, R7, R8, R9, R10 и R11. В полученной БД имеет место необходимое дублирование данных, но отсутствует избыточное.

2.3 Проектирование базы данных «Спортивный клуб» в соответствии с методом «сущность-связь»

Метод сущность-связь называют также методом «ER-диаграмм»: во-первых, ER - аббревиатура от слов Essence (сущность) и Relation (связь), во-вторых, метод основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.

Правила формирования отношений основываются на учете следующего:

*степени связи между сущностями (1:1,1:М, М:1, М:М);

*класса принадлежности экземпляров сущностей (обязательный и необязательный).

Рассмотрим формулировки шести правил формирования отношений на основе диаграмм ER-типа.

Формирование отношений для связи 1:1

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

На рис.1 приведены диаграмма ER-типа и отношение, сформированное по правилу 1 на ее основе.

Рис. 1. Формирование отношения по правилу 1 [12]

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

На рис.2 приведены диаграмма ER-типа и отношения, сформированные по правилу 2 на ее основе.

Рис. 2. Формирование отношения по правилу 2 [12]

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

На рис. 3 приведены диаграмма ER-типа и отношения, сформированные по правилу 3 на ее основе.

Рис. 3. Формирование отношения по правилу 3 [12]

Формирование отношений для связи 1:М .

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

На рис. 4. приведены диаграмма ER-типа и отношения, сформированные по правилу 4 на ее основе.

Рис. 4. Формирование отношения по правилу 4 [12]

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

Рис. 5 Формирование отношения по правилу 5 [12]

Формирование отношений для связи М:М

Правило 6. Если степень связи М:М, то независимо от класса принадлежности сущностей формируются три отношения. Два отношения соответствуют связываемым сущностям и их ключи являются первичными ключами этих отношений. Третье отношение является связным между первыми двумя, а его ключ объединяет ключевые атрибуты связываемых отношений.

На рис. 6 приведены диаграмма ER-типа и отношения, сформированные по правилу 6. [12]

Рис. 6. Формирование отношения по правилу 6 [12]

В моей БД «Спортивный клуб» имеются следующие сущности:

Клиенты (Ключ - Код клиента,…)

Тренеры (Ключ - Код тренера,…)

Занятия (Ключ - Код тренера, № дня недели,…)

Учет (Ключ - Код клиента, Начало действия абонемента,…)

Виды занятий (Ключ - Код вида занятия,…)

Залы (Ключ - № зала,…)

Количество занятий (Ключ - Оплата,…)

Оклад (Ключ - Стаж работы, лет,…)

Дни недели (Ключ - № дня недели,…)

Связи между сущностями:

Клиенты ЗАНИМАЮТСЯ У Тренеров (правило 4)

Занятия ВЕДУТ Тренеры (правило 6)

Занятия ВЕДУТСЯ ПО Дням недели (правило 4)

Занятия ПОДРАЗДЕЛЯЮТЯ НА Виды занятий (правило 4)

Занятия ПРОХОДЯТ В Залах (правило 4)

Учет ВЕДЕТСЯ ПО Клиентам (правило 4)

Учет ЗАВИСИТ ОТ Количества занятий (правило 4)

Тренеры ИМЕЮТ Оклад (правило 4)

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

Рис. 7. Диаграмма ER-типа «Спортивный клуб»

После добавления неключевых атрибутов в схему, отношения примут следующий вид:

Клиенты (*Код клиента, ФИО клиента, Дата рождения, Телефон, Код тренера)

Тренеры (*Код тренера, ФИО тренера, Адрес, Телефон; Серия, № паспорта; Дата рождения; Стаж работы, лет)

...