Автор: Пользователь скрыл имя, 10 Марта 2012 в 17:56, дипломная работа
Для современных условий характерно применение на предприятиях, в учреждениях и организациях высокоэффективной информационной системы, основанной на использовании новейших технических средств автоматизированной обработки цифровой и текстовой информации на базе компьютеров, объединенных в единую локальную вычислительную сеть.
Особое значение имеет развитие автоматизированных систем разного уровня. Одним из глобальных вопросов в автоматизации является связка между собой звеньев автоматизированной системы учреждения и дальнейшая интеграция различных автоматизированных систем в единый комплекс.
1 Описание предметной области
2 Постановка задачи
3 Обзор возможных средств решения поставленной задачи
3.1 Концепция баз данных
3.2 Архитектура субд
3.3 Инфологическая модель данных "сущность-связь"
3.4 Построение инфологической модели предметной области методом ER–диаграммы
3.5 Описание диаграммы «сущность-связь»
3.6 Реляционная структура данных
4 Разработка схемы базы данных и ее нормализация
4.1 О нормализации, функциональных и многозначных зависимостях
4.2 Потенциальные ключи
4.3 Ссылочная целостность
4.4 Первичные и внешние ключи
4.5 Потенциальные ключи и null – значения
4.6 Ограничение целостности
4.7 Описание логической схемы базы данных
5 Инструментальные средства и алгоритм реализации ИС
5.1 Обоснование выбора средств реализации
5.2 Разработка интерфейса пользователя
5.3 Описание данных БД «тестер»
5.4 Заполнение базы данных
5.5 Назначение ис «тестер»
5.6 Руководство пользователя для работы с программой «Тестер»
5.6.1 Создание тестовых заданий
5.6.2 Поиск и редактирование данных.
5.6.3 Процесс тестирования.
5.7 Описание характеристик программного продукта
Выводы
б) При попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ, происходит разделение операции на подоперации:
1) КАСКАДИРУЕТСЯ – операция удаления "каскадируется" с тем, чтобы удалить также дисциплины этого сотрудника;
2) ОГРАНИЧИВАЕТСЯ – удаляются лишь те сотрудники, которые не читают никакие дисциплины. Иначе операция удаления отвергается;
3) УСТАНАВЛИВАЕТСЯ – для всех дисциплин удаляемого сотрудника NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот сотрудник удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.
в) При попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ, может быть предпринята попытка обновить номер такого сотрудника, для которого имеется, по крайней мере, одна соответствующая дисциплина. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении:
1) КАСКАДИРУЕТСЯ – операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ в дисциплинах этого сотрудника;
2) ОГРАНИЧИВАЕТСЯ – обновляются первичные ключи лишь тех сотрудников, которые еще не читали дисциплины. Иначе операция обновления отвергается;
3) УСТАНАВЛИВАЕТСЯ – для всех дисциплин такого сотрудника NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ сотрудника. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.
Таким образом, для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющих этот внешний ключ, и целевую таблицу, которая идентифицируется этим ключом, но также и ответы на указанные выше вопросы (три ограничения, которые относятся к этому внешнему ключу).
Обозначение представляется внешним ключом в таблице, соответствующей этой характеристике. Но три рассмотренные выше ограничения на внешний ключ для данного случая должны специфицироваться следующим образом:
NULL-значения не допустимы
УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ
ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ
Указанные спецификации представляют зависимость по существованию характеристических сущностей.
Один из потенциальных ключей – первичный ключ. Остальные альтернативные ключи. Вместе с понятием первичного ключа система включает правило целостности объектов: ни один из атрибутов первичного ключа базового отношения не может быть null – значением (так как первичный ключ служит для идентификации объектов).
Это правило применимо только для базовых отношений. Другие отношения могут иметь первичный ключ, для которого null – значения допустимы. Правило применимо только для первичных ключей. Для альтернативных ключей null – значения могут быть запрещены или разрешены. Если запрещены, то такой альтернативный ключ не может быть выбран в качестве первичного ключа.
Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени.
Проблема целостности состоит в обеспечении, насколько это возможно, правильности данных в базе данных в любой момент времени. Однако эта цель может быть достигнута лишь в определенных пределах. В частности, система не может контролировать правильности каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 35 (представляющее число проработанных часов в неделю) в действительности должно быть равно 33. С другой стороны, значение 350 явно будет ошибочным, и система его отвергнет. Однако независимо от ограничений подобного рода должна существовать возможность (и это весьма желательно) поддержки высокой степени целостности в базе данных.
Поддержание целостности базы данных может рассматриваться как защита данных от неверных (в противоположность незаконным) изменений или разрушений. Этим проблема поддерживания целостности отличается от проблемы безопасности, хотя эти два вопроса тесно соприкасаются, и во многих случаях может быть использован, по крайней мере, частично, один и тот же механизм для достижения обеих целей. Например, процедура АССЕSS СОNTROL LOCK системы DBTG может быть использована не только для санкционирования некоторых операций, но также для обеспечения целостности. В общем случае с каждым отношением в базе данных может быть связан набор ограничений целостности. Подобно ограничениям безопасности, ограничения целостности будут содержаться в словаре данных как часть концептуальной схемы. Типичные ограничения могут определять, например, что значения конкретного атрибута отношения должны лежать в некоторых границах или что в пределах каждого кортежа отношения значение одного атрибута не может превышать значение другого.
Поддержание целостности в соответствии с подобными ограничениями представляет собой достаточно большую проблему (причем такую, в отношении которой отсутствует какой-либо существенный опыт) даже в системе с одним пользователем, т. е. в системе, в которой в каждый отдельный момент времени с базой данных может работать не более одного пользователя. В системах со многими пользователями, т. е. в системах, которые допусками временный доступ нескольких пользователей к базе данных, возникают дополнительные проблемы, например, такие, как проблемы управления совместно используемыми данными. В этом случае могут возникать некоторые трудности.
В общем случае целостность может быть нарушена в одной из следующих ситуаций: сбой оборудования в какой-либо точке системы. Отсюда следует, что потеря целостности возможна: в хорошо проверенных системах, так как любая из этих ошибок может от времени возникать, как бы хорошо ни была налажена система.
Выделяют три группы правил целостности:
целостность по сущностям;
целостность по ссылкам;
целостность, определяемая пользователем.
Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.
Значение внешнего ключа должно либо:
быть равным значению первичного ключа цели;
быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.
Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется:
уникальность тех или иных атрибутов;
диапазон значений;
принадлежность набору значений.
Связь между таблицами определяется отношением подчиненности, при котором одна таблица является главной, а вторая – подчиненной. Саму связь называют связь «главной-подчиненной». Существуют следующие виды связи:
− отношение «один к одному»;
− отношение «один ко многим»;
− отношение «многие к одному»;
− отношение «многие ко многим».
В БД отношения «один ко многим», это означает, что 1 записи в главной таблице соответствует несколько записей в подчиненной, а отношение «один к одному» означает, что одной записи в главной таблице соответствует лишь одно запись в подчиненной таблице.
Логическая схема базы данных имеет вид:
STUD (FIO_stud, Gruppa, Parol)
GRUPPA (Gruppa, Kurator)
PREPOD (FIO_prep, Dostup, Dolgnost, Parol)
DOLGNOST (Dolgnost)
DOSTUP (Dostup)
RESULT (FIO_stud, Test, Gruppa, Totall_ball)
FIO_stud | Grupa | Parol |
Gruppa | Kurator |
FIO_Prep | Dostup | Dolgnost | Parol |
Dostup | Opisanie |
Dolgnost |
FIO_stud | Test | Gruppa | Totall_Ball |
Рисунок 4.1 – Логическая схема данных
На сегодняшний день Ассеss является одной из самых популярных настольных СУБД. Это связано с тем, что Ассеss обладает очень широким диапазоном средств для ввода, анализа и представления данных. Эти средства являются не только простыми и удобными, но и высокопродуктивными, что обеспечивает высокую скорость разработки приложений. Изначально Ассеss обладала рядом уникальных возможностей, такими как умение, сводить воедино информацию из самых разных источников (электронных таблиц, текстовых файлов, других баз данных); представление данных в удобном для пользователя виде с помощью таблиц, диаграмм, отчетов; интеграция с другими компонентами Microsoft Office 2003. Совершенствуясь от версии к версии, Ассеss стала инструментом, который может удовлетворить самые разные категории пользователей: от новичка, которому нравится дружественный интерфейс системы, позволяющий ему справиться с малыми задачами, до профессионального разработчика, который имеет весь необходимый инструментарий построения уникального решения для конкретного предприятия среднего бизнеса.
В отличие от других настольных СУБД, Ассеss хранит все данные в одном файле, хотя и распределяет их по разным таблицам. Самым важным правилом, которое требуется соблюдать, является то, что в базе данных нужно хранить только необходимую информацию, и при этом все данные должны храниться только в одном месте, т. е. не должно быть дублирования информации.
СУБД Microsoft Access 2003 ориентированы на работу с объектами семи различных типов: таблицами, запросами, формами, отчётами, страницами, макросами, модулями.
Таблицы – это основной объект базы данных, в котором хранятся все данные, имеющиеся в базе, а также структура базы (поля, их типы, свойства).
Запросы позволяют выбирать данные из одной или нескольких связанных таблиц. Результатом выполнения запроса является результирующая таблица, которая наряду с другими таблицами может быть использована при обработке данных. С помощью запросов можно также обновлять, удалять или добавлять данные в таблицы.
Формы служат для ввода и просмотра данных в удобном для пользователя виде, который соответствует привычному для него документу. При выводе данных с помощью форм можно применять специальные средства оформления.
Отчёты предназначены для формирования выходных документов и вывода их на печать. По своим свойствам и структуре отчёты во многом подобны формам. Основное их отличие заключается в том, что в отчёте отображаются все данные и в них предусмотрена возможность группировать данные по различным критериям. Отчёты в отличие от форм могут содержать специальные элементы оформления, характерные для печати документов: колонтитулы, номера страниц и т.д.