Главная
База знаний "Allbest"
Программирование, компьютеры и кибернетика
Проектирование баз данных горнолыжной базы
Проектирование баз данных горнолыжной базы
Основы проектирования базы данных (БД). Модели, типы и функциональные возможности БД. Практическая разработка БД для горнолыжной базы. Сохранение данных в таблицах. Типы запросов как средства выбора необходимой информации. Создание отчетов и макросов.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 12.06.2014 |
| Размер файла | 53,3 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Федеральное государственное автономное образовательное учреждение высшего профессионального образования
Южный федеральный университет
Высшая школа бизнеса
Экономический колледж
Курсовая работа
по дисциплине "Проектирование баз данных"
на тему: "Проектирование баз данных горнолыжной базы"
Выполнил: студент
2 курса группы 2012-с-ис
Буханцов Алексей Алексеевич
Научный руководитель:
Коноваленко Владимир Александрович
Ростов-на-Дону
2013 г.
Оглавление
- Введение
- 1. Основы и проектирование БД
- 1.1 Основные модели БД
- 1.2 Функционирование и возможности БД
- 1.3 Типы БД
- 1.4 Вывод
- 2. Практическая часть. Разработка БД
- 2.1 Создание таблиц
- 2.2 Создание запросов
- 2.3 Создание отчетов
- 2.4 Создание макросов
- Вывод
- Список литературы
Введение
В настоящее время практически во всех организациях используются компьютеры для хранения и обработки служебной информации. Эта информация содержится в так называемых базах данных. Базы данных играют особую роль в современном мире. Все, с чем мы ежедневно сталкиваемся в жизни, скорее всего, зарегистрировано в той или иной базе. Умение работать с базами данных является одним из важнейших навыков в работе с компьютером, а специалисты этой области всегда окажутся востребованными.
Эти базы данных образовываются и функционируют под управлением специальных программных комплексов (совокупностей языков программирования и программных средств), называемых системами управления базами данных (СУБД). Сама база данных - это хранилище для большого количества систематизированных данных, с которыми можно производить определённые действия: добавления, удаления, изменения, копирования, упорядочивание.
Увеличение объема хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД. Для обеспечения одновременного доступа к данным множества пользователей, нередко расположенных достаточно далеко друг от друга и от места хранения баз данных, созданы сетевые мультипользовательские версии баз данных основанных на реляционной структуре. В них тем или иным путем решаются специфические проблемы параллельных процессов, целостности (правильности) и безопасности данных, а также санкционирования доступа.
За последние несколько наблюдается тенденция к усложнению структур данных. Простые виды информации, представимой в форме чисел и текстовых строк, не утратив своей значимости, дополняются сегодня многочисленными мультимедийными документами, графическими образами, хронологическими рядами, процедурными, или активными, данными и мириадами прочих сложных информационных форм. В связи с этим появилась целая плеяда весьма изощренных СУБД, поддерживающих новые коллекции данных и способных реализовать преимущества современных аппаратных средств.
Необходимость изучения свойств существующих и разработки новых баз данных обосновывает актуальность данной курсовой работы.
Цель курсовой работы:
1) Изучение особенностей,
2) Разработка БД,
3) Создание форм для ввода данных, отчетов, запросов,
4) Автоматизация работы с данной БД.
база запрос отчет макрос
1. Основы и проектирование БД
1.1 Основные модели БД
Иерархическая модель данных - представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами (в программировании применительно к структуре данных дерево устоялось название братья).
Первые системы управления базами данных использовали иерархическую модель данных.
Объектные базы данных - это модель работы с объектными данными.
Такая модель баз данных, несмотря на то, что она существует уже много лет, считается новой. И её создание открывает большие перспективы, в связи с тем, что использование объектной модели баз данных легко воспринимается пользователем, так как создается высокий уровень абстракции
Объектно-ориентированная база данных (ООБД) - база данных, в которой данные моделируются в виде объектов, их атрибутов, методов и классов.
Объектно-реляционная СУБД (ОРСУБД) - реляционная СУБД (РСУБД), поддерживающая некоторые технологии, реализующие объектно-ориентированный подход: объекты, классы и наследование реализованы в структуре баз данных и языке запросов.
Объектно-реляционными СУБД являются, к примеру, широко известные Oracle Database, Informix, DB2, PostgreSQL, FirstSQL/J.
Реляционная модель данных (РМД) - логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная модель данных включает следующие компоненты:
· Структурный аспект (составляющая) - данные в базе данных представляют собой набор отношений.
· Аспект (составляющая) целостности - отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
· Аспект (составляющая) обработки (манипулирования) - РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
Термин "реляционный" означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину "отношение" часто встречается слово таблица. Необходимо помнить, что "таблица" есть понятие нестрогое и неформальное и часто означает не "отношение" как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина "таблица" вместо термина "отношение" нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с "плоскими", или "двумерными" таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни "плоскими", ни "неплоскими".
Для лучшего понимания РМД следует отметить три важных обстоятельства:
· модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
· для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно - явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
· наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
Принципы реляционной модели были сформулированы в 1969-1978 годах Э.Ф. Коддом. Идеи Кодда были впервые публично изложены в статье "A Relational Model of Data for Large Shared Data Banks", ставшей классической.
Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. "C. J. Date. An Introduction to Database Systems" ("Дейт, К. Дж. Введение в системы баз данных").
Наиболее известными альтернативами реляционной модели являются иерархическая модель, и сетевая модель. Некоторые системы, использующие эти старые архитектуры, используются до сих пор. Кроме того, можно упомянуть об объектно-ориентированной модели, на которой строятся так называемые объектно-ориентированные СУБД, хотя однозначного и общепринятого определения такой модели нет.
Сетевая модель данных - логическая модель данных, являющаяся расширением иерархического подхода, строгая математическая теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в сетевых базах данных.
1.2 Функционирование и возможности БД
Непосредственное управление данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД.
Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
Заметим, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
Управление транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.
То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
Поддержка языков БД
Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Мы рассмотрим более подробно языки ранних СУБД в следующей лекции.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). В нескольких лекциях этого курса язык SQL будет рассматриваться достаточно подробно, а пока мы перечислим основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (т.е. функции, поддерживаемые при реализации интерфейса SQL).
Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
Более точное описание возможных реализаций этих функций на основе языка SQL будет приведено в лекциях, посвященных языку SQL и его реализации.
1.3 Типы БД
По технологии обработки данных базы данных подразделяются на централизованные и распределенные.
Централизованная база данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК.
Распределенная база данных состоит из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных (СУРБД).
По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным доступом.
Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем;
o файл-сервер;
o клиент-сервер.
Файл-сервер.
Архитектура систем БД с сетевым доступом предполагает выделение одной из машин сети в качестве центрального сервера файлов. На такой машине хранится совместно используемая централизованная БД. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользовательской системы к централизованной базе данных. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также на рабочих станциях локальные БД, которые используются ими монопольно.
Клиент-сервер.
В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные, но не файлы транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SQL.
По степени универсальности различают два класса СУБД:
системы общего назначения;
специализированные системы.
СУБД общего назначения не ориентированы на какую-либо предметную область или на информационные потребности какой-либо группы пользователей. Каждая система такого рода реализуется как программный продукт, способный функционировать на некоторой модели ЭВМ в определенной операционной системе и поставляется многим пользователям как коммерческое изделие. Такие СУБД обладают средствами настройки на работу с конкретной базой данных. СУБД общего назначения - это сложные программные комплексы, предназначенные для выполнения всей совокупности функций, связанных с созданием и эксплуатацией базы данных информационной системы.
Использование СУБД общего назначения в качестве инструментального средства для создания автоматизированных информационных систем, основанных на технологии баз данных, позволяет существенно сокращать сроки разработки и экономить трудовые ресурсы. Этим СУБД присущи развитые функциональные возможности и определенная функциональная избыточность.
Специализированные СУБД создаются в редких случаях при невозможности или нецелесообразности использования СУБД общего назначения.
1.4 Вывод
В этом параграфе мы рассмотрели:
1) Основные модели БД
2) Функционирование и возможности БД
3) Типы БД
2. Практическая часть. Разработка БД
2.1 Создание таблиц
При создании базы данных данные сохраняются в таблицах - списках строк и столбцов, относящихся к конкретной области. Например, можно создать таблицу "Контакты" для сохранения имен, адресов и телефонных номеров или таблицу "Товары" для сохранения сведений об этих товарах. Определение структуры базы данных необходимо всегда начинать с создания ее таблиц. Таблицы создаются раньше любых других объектов базы данных.
Перед созданием таблиц необходимо тщательно проанализировать требования к базе данных и создать ее план, чтобы точно выяснить, какие таблицы нужны.
Таблица содержит данные по определенной теме, например, сведения о сотрудниках или товарах. Каждая запись в таблице включает данные об одном элементе, например о конкретном сотруднике. Запись состоит из полей и включает такие сведения, как имя, адрес и телефонный номер. Кроме того, запись обычно называется строкой, а поле - столбцом.
В простой базе данных, такой как список контактов, можно использовать всего одну таблицу. Однако во многих базах данных используется несколько таблиц. При создании новой базы данных на компьютере создается новый файл, который используется как контейнер для всех объектов в базе данных, включая таблицы. Таблицу можно создать с помощью создания новой базы данных, вставки таблицы в существующую базу данных, а также импорта или создания ссылки на таблицу из другого источника данных, такого как книга Microsoft Office Excel 2007, документ Microsoft Office Word 2007, текстовый файл или другая база данных. При создании новой базы данных в нее автоматически вставляется новая пустая таблица. Затем можно ввести "Абонемент", "Апартаменты", "Клиент", "Резервирование", "Снаряжение", "Типы снаряжения".
2.2 Создание запросов
Запрос - это средство выбора необходимой информации из базы данных. Вопрос, сформированный по отношению к базе данных, и есть запрос.
Существует несколько типов запросов: на выборку, на обновление, на добавление. Наиболее распространенным является запрос на выборку. Запросы на выборку используются для отбора нужной пользователю информации, содержащейся в таблицах. Они создаются только для связанных таблиц.
1. Запросы на выборку
Запрос на выборку, является наиболее часто используемым типом запроса. Запросы этого типа возвращают данные из одной или нескольких таблиц и отображают их в виде таблицы, записи в которой можно обновлять (с некоторыми - ограничениями). Запросы на выборку можно также использовать для группировки записей и вычисления сумм, средних значений, подсчета записей и нахождения других типов итоговых значений.
2. Запросы на обновление
С помощью запроса на обновление можно добавлять, изменять или удалять данные в одной или нескольких записях. Запросы на обновление можно рассматривать как разновидность диалогового окна Поиск и замена с более широкими возможностями. Следует ввести условие отбора (приблизительный аналог образца поиска) и условие обновления (приблизительный аналог образца замены). В отличие от диалогового окна Поиск и замена запрос на обновление может принимать несколько
условий и позволяет обновить большое число записей за один раз, а также изменить записи сразу в нескольких таблицах.
3. Запросы на добавление
Запрос на добавление добавляет набор записей (строк) из одной или нескольких исходных таблиц (или запросов) в одну или несколько результирующих таблиц. Обычно исходные таблицы и конечная таблица находятся в одной и той же базе данных, но это не обязательно. Например, появилось несколько новых клиентов, а также база данных, содержащая сведения о них. Чтобы не вводить новые данные вручную, их можно добавить в соответствующую таблицу имеющейся базы данных.
1 - Запрос "Двухместные номера"
2 - Запрос "Занятые номера"
3 - Запрос "Зарезервированные номера"
4 - Запрос "Номера класса полу люкс"
5 - Запрос "Свободные Апартаменты"
6 - Запрос "Счет"
2.3 Создание отчетов
Отчет - это форматированное представление данных, которое выводится на экран, в печать или файл. Они позволяют извлечь из базы нужные сведения и представить их в виде, удобном для восприятия, а также предоставляют широкие возможности для обобщения и анализа данных.
При печати таблиц и запросов информация выдается практически в том виде, в котором хранится. Часто возникает необходимость представить данные в виде отчетов, которые имеют традиционный вид и легко читаются. Подробный отчет включает всю информацию из таблицы или запроса, но содержит заголовки и разбит на страницы с указанием верхних и нижних колонтитулов.
Прежде чем приступать к работе, следует выбрать источник, из которого будут извлекаться записи отчета. Отчет может представлять собой как простой список, так и подробную сводку данных о продажах, сгруппированных по районам. Однако в любом случае необходимо сначала определить, в каких полях содержатся данные, которые должны войти в отчет, и в каких таблицах или запросах находятся эти поля.
После того как выбран источник записей для создания отчета, проще всего воспользоваться мастером отчетов. Мастер отчетов - это средство Microsoft Access, помогающее создать отчет на основании ответов, полученных на заданные пользователю вопросы.
В мастере отчетов предоставляется больше возможностей относительно выбора полей для включения в отчет. При этом можно указать способ группировки и сортировки данных, а также включить в отчет поля из нескольких таблиц или запросов, если отношения между этими таблицами и запросами заданы заранее.
1 - Отчет "Абонемент"
2 - Отчет "Апартаменты"
3 - Отчет "Двухместные номера"
4 - Отчет "Занятые номера"
5 - Отчет "Зарезервированные номера"
6 - Отчет "Клиент"
7 - Отчет "Номера класса полу люкс"
8 - Отчет "Проживающие клиенты"
9 - Отчет "Прокат"
10 - Отчет "Резервирование"
11 - Отчет "Свободные апартаменты"
12 - Отчет "Снаряжение"
13 - Отчет "Счет"
14 - Отчет "Типы Снаряжения"
2.4 Создание макросов
Макрос - программный алгоритм действий, записанный пользователем.
Можно создать макрос, чтобы выполнять определенный набор макрокоманд или группу макросов, чтобы выполнять связанный набор макрокоманд. Макрокоманды выполняют такие действия, как открытие таблиц и форм, выполнение запросов, запуск других макросов, выбор опций из меню, изменение размеров открытых окон и т.п.
В Microsoft Office Access макросы могут содержаться в объектах макроса (иногда их называют изолированными макросами) или могут быть внедрены в свойства событий форм, отчетов, элементов управления. Внедренные макросы становятся частью объекта или элемента управления. Объекты макроса отображаются в области переходов в группе Макросы; внедренные макросы не отображаются.
Вывод
В результате написания данной работы мы можем сделать следующие выводы:
1. База данных (БД) - это поименованная совокупность структурированных данных, относящихся к определенной предметной области.
2. Система управления базами данных (СУБД) - это комплекс программных и языковых средств, необходимых для создания баз данных, их поддержания в актуальном состоянии и организации в них поиска необходимой информации.
3. К основным функциям СУБД принято относить следующие: управление данными во внешней памяти; управление буферами оперативной памяти; управление транзакциями; журнализация и восстановление БД после сбоев; поддержка языков БД.
4. Базовыми моделями представления данных являются иерархическая, сетевая и реляционная.
5. Экономические задачи, для решения которых необходимо применять программное обеспечение СУБД, весьма обширны и разнообразны. На его основе строятся информационные системы предприятий различных уровней.
6. Наиболее распространенными СУБД на сегодняшний день являются Microsoft Access и Visual FoxPro.
7. Microsoft Access - реляционная СУБД корпорации Microsoft, обладает интуитивно понятным интерфейсом. Имеет широкий спектр функций, включая связанные запросы, сортировку по разным полям, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.
8. Visual FoxPro - удобный инструмент для разработки баз данных.
Также можно сделать следующее предложение по совершенствованию создания и хранения баз данных:
Базы данных - это особые структуры. Информация, которая в них содержится, очень часто имеет общественную ценность. Нередко с одной и той же базой работают тысячи людей по всей стране. От информации, которая содержится в некоторых базах, может зависеть благополучие множества людей. Поэтому целостность содержимого базы не может и не должна зависеть ни от конкретных действий некоего пользователя, забывшего сохранить файлы перед выключением компьютера, ни от перебоев в электросети.
Проблема безопасности баз данных решается тем, что в СУБД для сохранения информации используется двойной подход. В части операций, как обычно, участвует операционная система компьютера, но некоторые операции сохранения происходят в обход операционной системы.
Средства защиты баз данных, реализованные в MS Access, позволяют предотвратить умышленные или случайные просмотр, изменение и удаление информации лицами, которые не имеют соответствующих прав доступа. Эти средства особенно важны при функционировании баз данных в сети.
В MS Access предусмотрены различные уровни защиты данных и администрирования доступа к ним. Возможности MS Access позволяют обеспечить безопасность, как самого приложения, так и файла базы данных. Простейшим средством защиты баз данных от несанкционированного доступа является пароль.
После того как пароль установлен, при каждом открытии базы данных будет появляться диалоговое окно, в которое требуется ввести пароль. Пользователи смогут открыть базу данных, только после ввода правильного пароля. Этот способ достаточно надежен, поскольку MS Access шифрует пароль, так что к нему нет прямого доступа при чтении файла базы данных. Недостаток такого способа защиты в том, что он применяется только при открытии базы данных. После открытия базы данных все объекты становятся доступными для пользователя (если не определена защита на уровне пользователей). Для базы данных, которая совместно используется небольшой группой пользователей или на автономном компьютере, установка пароля обычно оказывается достаточной.
Усовершенствовать защиту позволяют средства поддержки рабочих групп, ведения учетных (регистрационных) записей, задания прав владения и прав доступа. С помощью средств защиты можно указать, какие операции по обработке объектов базы данных разрешается выполнять пользователю или группе пользователей. О каждом пользователе или группе ведутся учетные записи с указанием прав доступа
Для того чтобы исключить неправомерный доступ к информации нашей базы данным, мы устанавливаем пароль на запуск базы данных. А так же создаём две группы пользователей - администратор с полным доступом ко всем элементам базы данных, и операторы которые имеют ограниченный доступ, например, им нельзя удалять записи из таблиц и менять структуру форм и отчетов.
Наиболее удобным методом защиты является использование "Мастера Зашиты" находящемся в меню "Сервис", подменю "Защита", который последовательно предоставит администратору базы данных создать пользователей базы данных, разграничить из права и установить пароли для запуска базы данных различными пользователями.
Таким образом, можно заключить, что дальнейшее направления развитие баз данных - это усовершенствование обеспечения их безопасности.
Список литературы
1. Когаловский М.Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика.
2. Кузнецов С.Д. Основы баз данных. - 2-е изд. - М.: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний,
3. Дейт К. Дж. Введение в системы баз данных
4. Когаловский М.Р. Перспективные технологии информационных систем
5. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика
6. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс.
Размещено на Allbest.ru
Подобные документы
Разновидности систем управления базами данных. Анализ предметной области. Разработка структуры и ведение базы данных. Структурированный язык запросов SQL. Организация выбора информации из базы данных. Общие принципы проектирования экранных форм, макросов.
курсовая работа [3,1 M], добавлен 26.02.2016Особенности разработки инфологической модели и создание структуры реляционной базы данных. Основы проектирования базы данных. Разработка таблиц, форм, запросов для вывода информации о соответствующей модели. Работа с базами данных и их объектами.
курсовая работа [981,4 K], добавлен 05.11.2011Создание базы данных, планирование разработки и системные требования. Проектирование базы данных в среде Microsoft Access, элементы и типы данных. Создание таблицы и использование конструктора для их модернизации. Построение запросов и создание макросов.
курсовая работа [2,0 M], добавлен 16.04.2011Авторизация с каталогами проектирования базы данных магазина. Задачи базы данных: учет всех товаров, поиск и выдача данных о клиентах, адрес, телефоны, цена и наличие товара. Этапы проектирования базы данных. Схема данных, создание запросов и их формы.
реферат [1,6 M], добавлен 22.10.2009Осуществление анализа предметной области и определение модели базы данных. Реализация базы данных в среде Microsoft Access. Создание и исследование формы ввода информации, запросов с условиями выбора, диаграмм по результатам вычислений и отчетов.
курсовая работа [246,1 K], добавлен 19.10.2013Составление схемы концептуальной модели данных. Разработка структуры реляционной базы данных и интерфейса пользователя. Особенности главных этапов проектирования базы данных. Способы реализации запросов и отчетов. Специфика руководства пользователя.
курсовая работа [186,9 K], добавлен 18.12.2010Понятие базы данных, модели данных. Классификация баз данных. Системы управления базами данных. Этапы, подходы к проектированию базы данных. Разработка базы данных, которая позволит автоматизировать ведение документации, необходимой для деятельности ДЮСШ.
курсовая работа [1,7 M], добавлен 04.06.2015Сущности и функциональные зависимости базы данных. Атрибуты и связи. Таблицы базы данных. Построение ER-диаграммы. Организация ввода и корректировки данных. Реляционная схема базы данных. Реализация запросов, получение отчетов. Защита базы данных.
курсовая работа [2,4 M], добавлен 06.02.2016Рассмотрение теоретических основ проектирования. Анализ предметной области и разработка таблиц базы данных. Заполнение таблиц, поиск данных с помощью фильтра. Создание форм, разработка запросов. Создание и настройка отчетов, составление приложения.
курсовая работа [2,8 M], добавлен 01.06.2014Проектирование базы данных для удобства работы организатора и систематизации различных конференций. Создание таблиц в режиме конструктора и установление связей между ними, запросов, форм для ввода данных, главной кнопочной формы, макросов и отчетов.
курсовая работа [2,3 M], добавлен 25.10.2014
