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

Оглавление

• Введение
• 1. Техническое задание
• 1.1 Назначение программы
• 1.2 Требования к программе
• 1.3 Требования к программной документации
• 1.4 Стадии и этапы разработки
• 2. Теоретические аспекты проектирования БД
• 2.1 Этапы проектирования БД
• 2.2 Основные проблемы проектирования реляционных БД
• 3. Инфологическое проектирование ПО
• 3.1 Определение сущностей
• 3.2 Описание атрибутов
• 3.3 Установление связей между типами сущностей
• 3.4 Концепция функциональной зависимости
• 3.5 Нормализация БД
• 3.6 Спецификация всех объектов, входящих в модель
• 3.7 Построение инфологической модели ПО (Предметной области)
• 4.Выбор СУБД
• 5.Даталогическое проектирование
• 5.1 Спецификация файлов БД
• 5.2 Разработка даталогической модели данных
• 6. Описание средств обеспечения целостности данных
• 7. Разработка средств обеспечения безопасности данных
• 8. Реализация запросов на SQL
• 9. Описание программного средства
• 9.1 Требования к аппаратному и программному обеспечению
• 9.2 Функциональное назначение программы
• 9.3 Входные данные
• 9.4 Выходные данные
• 9.5 Руководство пользователя
• Заключение
• Список используемой литературы


Введение

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

БД подразделяются:

по технологии обработки

централизованная БД;

распределенная БД;

по способу доступа к данным

БД с локальным доступом;

БД с удаленным доступом.

Проектирование БД состоит из этапов:

Инфологическое проектирование

Даталогическое проектирование.

Т.е. проектирование БД состоит в построении комплекса взаимосвязанных моделей данных.

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

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

Назначение программы

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

Ставятся задачи:

· ведения документации

· обработки поисковых запросов

· ведение информации об товарах и клиентах.

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

Требования к программе

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

Требования к программной документации

Состав программной документации:

руководство пользователя;

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

Стадии и этапы разработки

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

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

2. Программирование.

Содержание работ - Создание базы данных "Студенты"

3. Разработка документации. Испытание программы.

Содержание работ - Разработка Руководства пользователя



2. Теоретические аспекты проектирования БД

2.1 Этапы проектирования БД

Системный анализ предметной области (определение целей создания системы, изучение предметной области и определение требований пользователей). Определяются границы предметной области. Накапливаются знания о предметной области.

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

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

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

Описание модели данных

Модель - это представление реальности, отражающее лишь избранные детали.

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

- идентифицируют типы логических структур данных, которые можно представить в данной модели;

- специфицируют: признаки данного типа, правила композиции структур данного типа из структур других типов; правила обработки этих структур.

Одним из наиболее революционных решений в области методов доступа к данным стала идея отделения логической структуры и манипуляции данными, как они понимаются конечными пользователем, от их физического представления, требуемого компьютерным оборудованием. Это решение представлено трехуровневой архитектурой БД в соответствии со стандартом ANSI/SPARC.

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

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

Классификация моделей данных

Документальные модели данных соответствуют представлению о слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке. Модели, основанные на языках разметки документов, связаны, прежде всего, со стандартным общим языком разметки - SGML (Standart Generalised Markup Language). Этот язык предназначен для создания разметки, он определяет допустимый набор тегов(ссылок), их атрибуты и внутреннюю структуру документа. Тезаурусные модели основаны на принципе организации словарей, содержат определенные языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели эффективно используются в системах-переводчиках, особенно многоязыковых переводчиках.

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

Теоретико-графовые модели данных. Эти модели отражают совокупность реального мира в виде графа взаимосвязанных объектов. В зависимости от типа графа иерархическую или сетевую модели.

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

Базовыми объектами являются:

- элемент данных;

- агрегат данных;

- запись;

- набор данных.

Элемент данных - это минимальная информационная единица, доступная пользователю с использованием СУБД. Агрегат данных соответствует следующему уровню обобщения в модели. В модели определении агрегаты двух типов: агрегат типа вектор и агрегат типа повторяющаяся группа. Записью называется совокупность агрегатов или элементов данных, моделирующая некоторый класс объектов реального мира. Набор отражает иерархическую связь между двумя типами записей.

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

- большим размером;

- хорошо определенными, повторяющимися запросами;

- хорошо определенными транзакциями;

- хорошо определенными приложениями.

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

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

Реляционная модель данных в настоящее время используется в большинстве коммерческих СУБД. Реляционная модель позволила пользователю не заботиться о физической структуре данных и не интересоваться ею. Два языка манипулирования данными - реляционная алгебра и реляционное исчисление, которые предлагают более эффективные средства доступа к данным и их обработки и сегодня являются основой коммерческих СУБД. Наименьшая единица данных реляционной модели - это отдельное атомарное (неразложимое) для данной модели значение данных. Домен - это некоторое множество элементов, например, множество значений, которые может принимать объект. Декартово произведение К доменов это множество всех кортежей длины К, то есть состоящих из К элементов, по одному из каждого домена. Отношением R на множествах D₁, D₂… D_k называется подмножество их декартова произведения. Элементами отношения являются кортежи. Отношение на доменах D₁, D₂… D_n состоит из заголовка и тела. Заголовок состоит из такого фиксированного множества атрибутов A₁, A₂,…, A_n, что существует взаимно однозначное соответствие между этими атрибутами A_i и определяющими их доменами D_i (i=1,2,…,n). Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (A_i:V_i), (i=1,2,…, n), по одной такой паре для каждого атрибута A_i в заголовке.

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

2.2 Основные проблемы проектирования реляционных БД

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

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

ПОСТАВКА (Назв_поставщика, Адрес, Товар, Количество, Цена).

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

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

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

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



3. Инфологическое проектирование ПО

3.1 Определение сущностей

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не конкретного экземпляра.

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

Предметная область «Приобретение товаров» включает в себя следующие сущности: «Менеджеры», «Город», «Адрес», «Клиенты», «Накладная», «Долг», «Оплата», «Товар», «Строка в накладной», «Руководитель».

3.2 Описание атрибутов

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

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

Сущность «Должности» включает в себя следующие атрибуты: код должности, наименование должности, оклад, обязанности и требования.

3.3 Установление связей между типами сущностей

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).



3.4 Концепция функциональной зависимости

Функциональная зависимость - В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными)в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y.

Полная функциональная зависимость - Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.

Транзитивная функциональная зависимость - Функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y и отсутствует функциональная зависимость R.Z --> R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)

Неключевой атрибут - любой атрибут отношения, не входящий в состав первичного ключа (в частности, первичного).

Взаимно независимые атрибуты -Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.

3.5 Нормализация БД

Нормализация отношений - процесс декомпозиции исходного отношения на более мелкие. Такая декомпозиция связана с центральной задачей проектирования БД: получение оптимального набора отношений и оптимального атрибутного состава. Задача группировки может решаться множеством способов, но требуется найти такой состав отношений, который удовлетворял следующим требованиям:

1) Множество отношений должно обеспечивать минимальную избыточность предоставления информации

2) Назначение для отношения - первичные ключи должны быть минимальными

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

4) Перестройка набора отношений при изменении структуры какого-либо отношения, например добавления новых атрибутов, должна быть минимальной.

5) Время выполнения запросов в БД должно быть небольшим.

Введено 5 уровней нормализации схем отношений и 5 нормальных форм: 1НФ, 2НФ, 3НФ, 4НФ, 5НФ, которые подчиняются правилу вложенности по возрастанию номеров.

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

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

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

3.6 Спецификация всех объектов, входящих в модель

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

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

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



3.7 Построение инфологической модели ПО (Предметной области)

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

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

Основные элементы данной модели:

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

- Описание информационных потребностей пользователей (описание основных запросов к БД).

- Описание алгоритмических зависимостей между данными.

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

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

- основные объекты предметной области (объекты, о которых должна -храниться информация в БД);

- атрибуты объектов;

- связи между объектами;

- основные запросы к БД.



4. Выбор СУБД

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

Характеристика СУБД Oracle:

· административное управление: отлично;

· графические инструменты: хорошо;

· простота обслуживания: отлично;

· механизм данных: отлично;

· работа с несколькими ЦП: отлично;

· функция соединения и выбор индексов: отлично;

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

· обработка мультимедиа данных: отлично;

· подключение к Web: отлично;

· обработка аудио, видео, изображений: отлично;

· поиск по всему тексту: отлично;

· функциональная совместимость: хорошо;

· сопряжение с другими БД: хорошо;

· единая регистрация: хорошо;

· работа под управлением различных ОС: хорошо;

· возможности программирования: отлично;

· хранимые процедуры и триггеры: отлично;

· внутренний язык программирования: отлично;

· построение баз данных: отлично;

· язык SQL: отлично;

· объектно-ориентированные системы: отлично;

· тиражирование: отлично;

· распределенная обработка транзакций: отлично;

· дистанционное администрирование: отлично;

· организация хранилищ данных и подготовка отчетов: отлично;

· средства загрузки: отлично;

· средства анализа: отлично.



5. Даталогическое проектирование

Логическое (даталогическое) проектирование - отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель - набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.

Определение состава базы данных:

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

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

Такой подход имеет очевидные достоинства:

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

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

5.1 Спецификация файлов БД

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

5.2 Разработка даталогической модели данных

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

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

Не все виды связи существующие в предметной области можно отобразить даталогической моделью. Так большинство СУБД не обеспечивают поддержание связи типа М:М. В этом случае в даталогической модели вводится вспомогательный элемент, т.е. M:N разбивается на два отношения между исходными элементами и вспомогательными (1:M, 1:N).

Рисунок 5.2 - Даталогическая модель БД



6. Описание средств обеспечения целостности данных

Категорная целостность (целостность сущностей)

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

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

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

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

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

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

· Значение некоторого атрибута должно удовлетворять определенному формату.

· Множество значений одного из атрибутов отношения должно удовлетворять статистическому условию.

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

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

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

· Вставка строки в родительскую таблицу.

· Удаление строки из родительской таблицы

· Обновление первичного ключа в строке родительской таблицы.



7. Разработка средств обеспечения безопасности данных

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

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

Основные компоненты системы защиты баз данных

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

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

· Защита доступа - доступ к данным может получить пользователь, прошедший процедуру идентификации и аутентификации.

· Шифрование данных - шифровать необходимо как передаваемые в сети данные для защиты от перехвата, так и данные, записываемые на носитель, для защиты от кражи носителя и несанкционированного просмотра/изменения не-средствами системы управления БД (СУБД).

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

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

инфологический даталогический база данный банк



8. Реализация запросов на SQL

SELECT Вкладчики

Код, Вкладчики.[ФИО вкладчика],

Вкладчики

Адрес AS Вкладчики_Адрес, Вкладчики.

Телефон AS Вкладчики_Телефон, Вкладчики. [Паспортные данные]

AS [Вкладчики_Паспортные данные],

Вкладчики. [Дата вклада],

Вкладчики. [Дата возврата],

Вкладчики. [Код вклада]

AS [Вкладчики_Код вклада],

Вкладчики. [Сумма вклада],

Вкладчики. [Сумма возврата],

Вкладчики. [Отметка о возврате вклада],

Вкладчики. [Код сотрудника]

AS [Вкладчики_Код сотрудника],

Вклады. [Код вклада]

AS [Вклады_Код вклада],

Вклады. [Наименование вклада],

Вклады. [Минимальный срок вклада],

Вклады. [Минимальная сумма вклада],

Вклады. [Код валюты],

Вклады. [Процентная ставка Дополнительные условия],

Вклады. [Дополнительные условия],

Сотрудники. [Код сотрудника]

AS [сотрудники_код сотрудника],

сотрудники. [ФИО сотрудника],

сотрудники. Возраст,

сотрудники. Пол,

сотрудники. Адрес AS

сотрудники_Адрес,

сотрудники Телефон

AS сотрудники_Телефон,

сотрудники. [Паспортные данные]

AS [сотрудники_Паспортные данные], сотрудники. [Код должности]

FROM сотрудники INNER JOIN (Вклады INNER JOIN Вкладчики ON

Вклады. [Код вклада] = Вкладчики. [Код вклада])

ON сотрудники. [код сотрудника] = Вкладчики. [Код сотрудника];

SELECT Вкладчики.

Код, Вкладчики. [ФИО вкладчика],

Вкладчики.Адрес AS

Вкладчики_Адрес,

Вкладчики. Телефон

AS Вкладчики_Телефон,

Вкладчики. [Паспортные данные]

AS [Вкладчики_Паспортные данные],

Вкладчики. [Дата вклада],

Вкладчики. [Дата возврата],

Вкладчики. [Код вклада]

AS [Вкладчики_Код вклада],

Вкладчики. [Сумма вклада],

Вкладчики. [Сумма возврата],

Вкладчики. [Отметка о возврате вклада],

Вкладчики. [Код сотрудника]

AS [Вкладчики_Код сотрудника],

Вклады. [Код вклада]

AS [Вклады_Код вклада],

Вклады. [Наименование вклада],

Вклады. [Минимальный срок вклада],

Вклады. [Минимальная сумма вклада],

Вклады. [Код валюты],

Вклады. [Процентная ставка Дополнительные условия],

Вклады. [Дополнительные условия],

сотрудники. [код сотрудника]

AS [сотрудники_код сотрудника],

сотрудники. [ФИО сотрудника],

сотрудники. Возраст,

сотрудники. Пол,

сотрудники. Адрес

AS сотрудники_Адрес,

сотрудники.Телефон

AS сотрудники_Телефон,

сотрудники. [Паспортные данные]

AS [сотрудники_Паспортные данные],

сотрудники. [Код должности]

FROM сотрудники INNER JOIN

(Вклады INNER JOIN Вкладчики ON Вклады

[Код вклада] = Вкладчики. [Код вклада]) ON сотрудники.[код

сотрудника] = Вкладчики. [Код сотрудника];

SELECT Валюты. [Код валюты]

AS [Валюты_Код валюты],

Валюты. Наименование, Валюты. [Обменный курс],

Вклады. [Код вклада],

Вклады. [Наименование вклада],

Вклады. [Минимальный срок вклада],

Вклады. [Минимальная сумма вклада],

Вклады. [Код валюты]

AS [Вклады_Код валюты],

Вклады. [Процентная ставка Дополнительные условия],

Вклады. [Дополнительные условия],

Вклады. [Код валюты]

FROM Валюты LEFT JOIN

Вклады ON Валюты.

[Код валюты] = Вклады.[Код валюты];





9. Описание программного средства

Данная программа разработана с помощью СУБД Access. Главная форма программы написана на языке высокого уровня Access



9.1 Требования к аппаратному и программному обеспечению

Программа предназначена для работы на IBM-совместимых персональных компьютерах, имеющих следующие минимальные характеристики: тактовая частота процессора - 200 МГц; оперативная память - 32 Мб; объем жестокого диска около 37 Мб.

9.2 Функциональное назначение программы

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

9.3 Входные данные

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

9.4 Выходные данные

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

9.5 Руководство пользователя

- Для работы с программой необходимо запустить базу данных bank.accdb

- После чего откроется база в среде Access

- Далее выбирается главная форма

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

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

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

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

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



Заключение

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

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

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



Список используемой литературы

1. Хомоненко Ф.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших заведений/Под ред. Хомоненко А.Д. - 4-е изд.- СПб.: КОРОНА,2004. -736 с.

2. Агальцов В.П. Базы данных. - М.: Мир,2002.-376 с.

3. Кузин А.В. Базы данных: учеб.пособие для студентов высш.учеб. заведений.- 2-е издание. - М.: Издательский центр «Академия», 208.-320 с.

4. Наместников А.М. Построение баз данных в среде Oracle. Практический курс.: Учеб. Пособие для вузов. Ульяновск: УлГТУ, 2008.

5. Сухарев М.В. Основы Delphi. Профессиональный подход - СПб.: Наука и техника, 2004. - 600 с.: ил.

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