Автор работы: Пользователь скрыл имя, 08 Ноября 2013 в 10:58, курсовая работа
В настоящее время среди разработчиков базы данных (БД) большой популярностью пользуется реляционная СУБД ACCESS, входящая в состав пакета Microsoft Office 2010. Дружественный интерфейс и простота настройки, эффективные средства создания таблиц, форм, запросов, интеграция с другими приложениями пакета, средства организации работы с базами данных и защита информации - вот далеко не полный перечень достоинств этого приложения.
1. Введение……………………………………………………………………….2
2. Проектирование базы данных………………………………………………..3
2.1 Анализ предметной области………………………………………………3
2.2 Проектирование инфологической, даталогической, физической моделей, построение ER-диаграммы…………………………………………5
3. Разработка базы данных……………………………………………………...7
Разработка схемы связей таблиц, нормализация базы данных и приведение ее к НФБК………………………………………………..…..7
3.2 Заполнение таблиц средствами Access………………………………....10
4. Создание базы данных……………………………………………………….12
Разработка форм и запросов средствами Access……………………….12
Разработка отчетов и макросов средствами Access…………………….13
5. Разработка руководства пользователю базой данных…………………...…16
5.1 Назначение и возможности базы данных……………………………….16
5.2 правила и порядок работы с базой данных……………………………..23
Заключение……………………………………………………………………….26
Список используемой литературы ……………………………………………..28
Приложения:
1.Схема связей таблиц «Сущность-связь»…………………………………..29
2.ER-диаграмма……………………………………………………………….29
3.Скрипты SQL-запросов………………………………………………….....30
Таким образом, любая СУБД должна обеспечивать следующее:
Обеспечение этих требований к информационным системам на уровне СУБД позволяет избегать повторения одной и той же работы при разработке программ. Механизмы реализации этих требований описываются ниже более подробно.
Возможности СУБД и их отличия от файловых систем.
Четкое разделение физической (скрытой) и логической (открытой) структуры данных в СУБД является продолжением той тенденции, которая наблюдалась на первых этапах развития компьютеров, когда низкоуровневый доступ к постоянной памяти (по адресу) заменялся на доступ по имени некоторой её области – файла. (Кстати, примерно то же самое произошло и в области языков программирования, где от явных адресов оперативной памяти перешли к именованным переменным). При использовании файлов программист вынужден помнить много лишней информации об их структуре, открывать, закрывать файлы и т.д., в то время как СУБД предоставляет данные по их смыслу (по названиям и другим атрибутам), а не по адресу, состоящему из имени файла и позиции указателя в этом файле. В связи с этим файлы сейчас используются, прежде всего, для последовательного доступа к данным, но не для произвольного (т.е. беспорядочного, random access) доступа. Современные же СУБД обеспечивают не только произвольный доступ к данным (навигацию по базе данных на основе атрибутов и связей данных), но иненавигационный доступ по так называемым запросам, в которых указываются условия отбора данных, а не их положение в БД.
При навигационном и, тем более, при ненавигационном доступе у СУБД возникают проблемы понижения скорости операций чтения и записи по сравнению с файловой системой. Поэтому среди основных функций СУБД была отмечена оптимизация запросов на выборку и изменение данных. Один из основных приёмов повышения скорости – буферизация данных в оперативной памяти. Она позволяет по запросам на выборку предоставлять ранее выбиравшиеся данные непосредственно из оперативной памяти, а по запросам на изменение сначала модифицировать данные лишь виртуально, и только при появлении в системе свободных ресурсов переписывать их из оперативной в более медленную постоянную память. Современные операционные системы также поддерживают буферизацию при работе с файлами, однако этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Оптимизации поиска данных также способствует их индексирование, то есть создание вспомогательных таблиц, сопоставляющих значению некоторой части искомых данных (входящей в условия запросов) физический(ие) адрес(а) блока(ов) данных, где хранится остальная часть. Помимо индексных таблиц, ради эффективности системам управления базами данных приходится поддерживать таблицы соответствия между смысловыми названиями логических объектов БД и их внутренними “адресами”.
Другой тип оптимизации
возникает при необходимости
Одним из способов решения
этой и других проблем в СУБД является
чёткое отделение данных, соответствующих
реальным объектам, от информации о
связях между этими объектами. Это
позволяет поддерживать
Для обеспечения логической целостности БД также применяется понятие транзакции, то есть последовательности операций над данными, не имеющих смысла по отдельности. Либо все операции транзакции завершаются успешно, либо (например, в случае непредвиденной ошибки) ни одна из них не отражается на данных в постоянной памяти (не фиксируется). В современных СУБД транзакции не фиксируются до тех пор, пока не поступит специальная команда (commit). До фиксации изменений в БД возможна их отмена (так называемый откат) другой командой (rollback).
Транзакции полностью реализованы, прежде всего, в СУБД, которые рассчитаны на одновременную работу многих пользователей (Oracle, MS SQL Server, IBM DB2, Informix, Sybase). С наличием большого числа пользователей разной квалификации связана также поддержка в этих СУБДпривилегий, которые ограничивают доступ к данным и этим повышают надёжность БД. Аналогичные возможности ограничения прав доступа к данным существуют и на уровне современных файловых систем (ОС Windows NT или Unix).
Многопользовательские СУБД обычно реализуются на основе архитектуры “клиент-сервер”, в которой данные хранятся на сервере, а представляются и редактируются пользователем на компьютерах-клиентах, объединенных вместе с сервером в сеть на основе какого-либо протокола транспортного уровня. Сетевые технологии также используются в т.н. распределённых СУБД, которые работают с одной и той же базой данных одновременно на большом количестве серверов. В мире файловых систем аналогичные возможности обеспечиваются, например, подключением сетевого диска в Windows или монтированием сетевого устройства в общую файловую систему Unix. Однако файловые системы не могут обеспечить обмен данными через сетевые протоколы более высокого – прикладного – уровня, в частности, использование сервисаWWW через протокол HTTP. Это существенно облегчает разработку информационных систем, поскольку на СУБД возлагается ответственность не только за извлечение, но и за представление данных пользователю (в виде Web-страниц).
Одним из основных требований к СУБД является надежность хранения данных в постоянной памяти возможность восстановления последнего согласованного состояния БД после любого аппаратного или программного сбоя. Для этого во многих СУБД существуют специальные файлы журнала изменений, в который записывается любая операция перед тем, как она модифицирует данные в БД. Журнал этого типа позволяет автоматически проводить откат незавершённых транзакций после неожиданной потери содержимого оперативной памяти (после мягкого сбоя). Второй тип журнала обеспечивает надёжность БД по отношению к жёсткому сбою (к выходу из строя устройства постоянной памяти): он хранится на другом устройстве вместе с резервной копией всей БД, которая периодически (например, раз в месяц) обновляется. При потере основной БД над резервной копией повторяются все транзакции, информация о которых записана в журнале. Конечно, надёжность достигается за счёт уменьшения производительности и некоторой избыточности данных при журналировании. Следует заметить, что некоторые современные файловые системы (в частности, NTFS) имеют аналогичные средства восстановления после (мягких) сбоев.
Таким образом, в число возможностей большинства современных СУБД входят:
Следует заметить, что информационные системы делятся на две группы: OLTP-системы, ориентированные на изменение детальной информации (On-Line Transaction Processing) и OLAP-системы, ориентированные на извлечение и анализ сильно агрегированных (обобщённых) данных (On-Line Analytical Processing). К СУБД, предназначенным для информационных систем второго типа, предъявляются несколько иные требования. В частности, необходимо обеспечить максимальную скорость выполнения запросов на выборку данных; для этого в предельных вариантах OLAP-систем (называемых хранилищами данных – data warehouses) хранятся результаты часто встречающихся сложных запросов, что приводит к дублированию данных. Кроме того, в таких системах журнализация и транзакции (пп. 2-3) не всегда нужны, часто они только замедляют выполнение запросов, а поддержка Web-технологий, не очень существенная для OLTP-систем, наоборот, является очень важной.
5.2 Правила и порядок работы с базой данных
В целом концепция реляционной модели определяется следующими двенадцатью правилами Кодда.
1. Правило информации. Вся информация в базе данных должна быть предоставлена исключительно на логическом уровне и только одним способом — в виде значений, содержащихся в таблицах.
2. Правило гарантированного доступа. Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путем использования комбинации имени таблицы, первичного ключа и имени столбца.
3. Правило поддержки недействительных значений. В реляционной базе данных должна быть реализована поддержка недействительных значений, которые отличаются от строки символов нулевой длины, строки пробельных символов, от нуля или любого другого числа и используются для представления отсутствующих данных независимо от типа этих данных.
4. Правило динамического каталога, основанного на реляционной модели. Описание базы данных на логическом уровне должно быть представлено в том же виде, что и основные данные, чтобы пользователи, обладающие соответствующими правами, могли работать с ним с помощью того же реляционного языка, который они поменяют для работы с основными данными.
5. Правило исчерпывающего подъязыка данных. Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать по крайней мере один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы:
• определение данных;
• определение представлений;
• обработку данных (интерактивную и программную);
• условия целостности;
• идентификацию прав доступа;
• границы транзакций (начало, завершение и отмена).
6. Правило обновления представлений. Все представления, которые
теоретически можно обновить, должны быть доступны для обновления.
7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при добавлении, обновлении и удалении данных.
8. Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.
9. Правило независимости логических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при внесении в базовые таблицы любых изменений, которые теоретически позволяют сохранить нетронутыми содержащиеся в этих таблицах данные.
10. Правило независимости условий целостности. Должна существовать возможность определять условия целостности, специфические для конкретной реляционной базы данных, на подъязыке реляционной базы данных и хранить их в каталоге, а не в прикладной программе.
11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.
12. Правило единственности. Если в реляционной системе есть низкоуровневый язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня (обрабатывающем несколько записей за один раз).
Правило два указывает
на роль первичных ключей при поиске
информации в базе данных. Имя таблицы
позволяет найти требуемую
Правило три требует, чтобы
отсутствующие данные можно было
представить с помощью
Правило четыре гласит, что реляционная база данных должна сама себя описывать. Другими словами, база данных должна содержать набор системных таблиц, описывающих структуру самой базы данных.
Правило пять требует, чтобы СУБД использовала язык реляционной базы данных, например SQL. Такой язык должен поддерживать все основные функции СУБД — создание базы данных, чтение и ввод данных, реализацию защиты базы данных и т. д.
Правило шесть касается представлений,
Правило семь акцентирует внимание на том, что базы данных по своей природе ориентированы на множества. Оно требует, чтобы операции добавления, удаления и обновления можно было выполнять над множествами строк. Это правило предназначено для того, чтобы запретить реализации, в которых поддерживаются только операции над одной строкой.
Правила восемь и девять означают отделение пользователя и прикладной программы от низкоуровневой реализации базы данных. Ониутверждают, что конкретные способы реализации хранения или доступа, используемые в СУБД, и даже изменения структуры таблиц базы данных не должны влиять на возможность пользователя работать с данными.
Правило 10 гласит, что язык базы данных должен поддерживать ограничительные условия, налагаемые на вводимые данные и действия, которые могут быть выполнены над данными.
Правило 11 гласит, что язык базы данных должен обеспечивать возможность работы с распределенными данными, расположенными на других компьютерных системах.
И, наконец, правило 12 предотвращает использование других возможностей для работы с базой данных, помимо языка базы данных, поскольку это может нарушить ее целостность.