Разработка информационной системы на MS Access

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

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

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

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

       моделирование и интеграция всех представлений.

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

1.5.2 Логическое проектирование 

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

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

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

1.5.3 Физическое проектирование 

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

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

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

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

1.6 Условия обеспечение целостности данных  

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

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

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

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

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

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

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

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

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

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

        

1.7 Нормализация данных 

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

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

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

       Всего в реляционной теории насчитывается  шесть нормальных форм:

       - первая нормальная форма (1НФ),

       - вторая нормальная форма (2НФ),

       - третья нормальная форма (3НФ),

       - нормальная форма Бойса-Кодда (НФБК),

       - четвертая нормальная форма (4НФ),

       - пятая нормальная форма (5НФ).

       Основное  свойство нормальных форм – при  переходе к каждой последующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

       Работа  с таблицами базы данных  

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

1.8 Средства разработки  

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

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

       В настоящее время существуют визуальные объектно-ориентированные версии инструментальных средств и СУБД на ПК (MSAccess, VisualFoxPro, CA-VisualObjects и VisualdBase). Эти продукты направлены сугубо на создание Windows-приложений и содержат средства объектно-ориентированного диалога, событийно-управляемого программирования, визуального конструирования интерфейса пользователя и многие другие черты, присущие системам программирования 4GL и средствам быстрой разработки RAD. Кроме того, они поддерживают структурный язык запросов SQL, который характерен для приложений клиент-сервер.

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

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

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

       Для реализации серверов БД используются системное ПО реляционных СУБД, понимающих язык запросов SQL, например: Oracle, Informix, Sybase, MSSQLServer. Многие из этих СУБД работают на различных аппаратных платформах и в средах разных ОС.

       Задача, поставленная в данной дипломной  работе, будет реализована средствами Microsoft Access. Рассмотрим кратко основные сведения об этой СУБД.

       Система Microsoft Access является одним из основных компонентов Microsoft Office и предназначена  для работы с реляционными базами данных. Особенность данной СУБД: вся  информация базы данных хранится в  одном файле (*.mdb). Кроме информации таблиц, в этом же файле сохраняются компоненты приложения для работы с базой данных - экранные формы, отчеты, запросы, программные модули.

       Для работы с базой данных система  использует Microsoft Jet database engine - систему  управления базами данных, извлекающую  и сохраняющую данные в пользовательских и системных задачах. Ядро базы данных Microsoft Jet можно рассматривать как компонент диспетчера данных, с помощью которого строятся остальные системы доступа к данным, такие как Microsoft Access и Microsoft Visual Basic.

       Язык  написания программных модулей  для работы с базой данных - Microsoft Visual Basic for Applications (VBA).

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