Описание базы данных. Распределение пространства на физических носителях. Интерфейс языка запросов и обновлений
Введение
Глава1. Основы баз данных
1.1.Классификация баз данных
1.3Модели описания баз данных
1.4. Основы работы настольных СУБД
1.5.Требования и стандарты, предъявляемые к базам данных
Глава 2. Работа с базой данных Microsoft Access
2.1. Основы работы настольной СУБД Microsoft Access
2.2. Работа с базой данных Microsoft Access
Заключение
Список использованной литературы
Введение
Потоки информации, циркулирующие в мире, который нас окружает, огромны. Во
времени они имеют тенденцию к увеличению. Поэтому в любой организации, как
большой, так и маленькой, возникает проблема такой организации управления
данными, которая обеспечила бы наиболее эффективную работу. Некоторые
организации используют для этого шкафы с папками, но большинство предпочитают
компьютеризированные способы – базы данных, позволяющие эффективно хранить,
структурировать и систематизировать большие объемы данных. И уже сегодня без баз
данных невозможно представить работу большинства финансовых, промышленных,
торговых и прочих организаций. Не будь баз данных, они бы просто захлебнулись в
информационной лавине.
Существует много веских причин перевода существующей информации на компьютерную основу. Сейчас стоимость хранения информации в файлах ЭВМ дешевле, чем на бумаге. Базы данных позволяют хранить, структурировать информацию и извлекать
оптимальным для пользователя образом. Данная тема актуальна в настоящее время, т.к. использование клиент/серверных технологий позволяют сберечь значительные средства, а главное и время для получения необходимой информации, а также упрощают доступ и ведение, поскольку они основываются на комплексной обработке данных и централизации их хранения. Кроме того ЭВМ позволяет хранить любые форматы данных, текст, чертежи, данные в рукописной форме, фотографии, записи голоса и т.д.
Для использования столь огромных объемов хранимой информации, помимо развития
системных устройств, средств передачи данных, памяти, необходимы средства
обеспечения диалога человек - ЭВМ, которые позволяют пользователю вводить
или принимать решения на основании хранимых данных. Для обеспечения этих функций
созданы специализированные средства – системы управления базами данных (СУБД).
Целью данной работы является раскрыть понятие базы данных и системы управления базами данных, а также рассмотреть на конкретном примере работу настольной СУБД.
1.1.Классификация баз данных
База данных – это информационная модель предметной области, совокупность взаимосвязанных, хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений. Данные (файлы) хранятся во внешней памяти и используются в качестве входной информации для решения задач.
СУБД - это программа, с помощью которой реализуется централизованное управление данными, хранимыми в базе, доступ к ним, поддержка их в актуальном состоянии.
Системы управления базами данных можно классифицировать по способу установления связей между данными, характеру выполняемых ими функций, сфере применения, числу поддерживаемых моделей данных, характеру используемого языка общения с базой данных и другим параметрам.
Классификация СУБД:
· по выполняемым функциям СУБД подразделяются на операционные и информационные;
· по сфере применения СУБД подразделяются на универсальные и проблемно-ориентированные;
· по используемому языку общения СУБД подразделяются на замкнутые, имеющие собственные самостоятельные языки общения пользователей с базами данных, и открытые, в которых для общения с базой данных используется язык программирования, расширенный операторами языка манипулирования данными;
· по числу поддерживаемых уровней моделей данных СУБД подразделяются на одно-, двух-, трехуровневые системы;
· по способу установления связей между данными различают реляционные, иерархические и сетевые базы данных;
· по способу организации хранения данных и выполнения функций обработки базы данных подразделяются на централизованные и распределенные.
Системы централизованных баз данных с сетевым доступом предполагают две основные архитектуры – файл-сервер или клиент-сервер.
Архитектура файл-сервер. Предполагает выделение одной из машин сети в качестве центральной (главный сервер файлов), где хранится совместно используемая централизованная база данных. Все другие машины исполняют роль рабочих станций. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится их обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает.
Архитектура клиент-сервер. Эта модель взаимодействия компьютеров в сети для современных СУБД фактически стала стандартом. Каждый из подключенных к сети и составляющих эту архитектуру компьютеров играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность пользоваться ими. Помимо хранения централизованной базы данных сервер базы данных обеспечивает выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запроса SQL.
Сервер базы данных представляет собой СУБД, параллельно обрабатывающую запросы, поступившие со всех рабочих станций. Как правило, клиент и сервер территориально отделены друг от друга, и в этом случае они образуют систему распределенной обработки данных.
1.2. Функциональные возможности СУБД
Характеристиками СУБД являются:
· производительность;
· обеспечение целостности данных на уровне баз данных;
· обеспечение безопасности данных;
· возможность работы в многопользовательских средах;
· возможность импорта и экспорта данных;
· обеспечение доступа к данным с помощью языка SQL;
· возможность составления запросов;
· наличие инструментальных средств разработки прикладных программ.
Производительность СУБД оценивается:
· временем выполнения запросов;
· скоростью поиска информации;
· временем импортирования баз данных из других форматов;
· скоростью выполнения операций (таких как обновление, вставка, удаление);
· временем генерации отчета и другими показателями.
· Безопасность данных достигается:
· шифрованием прикладных программ;
· шифрованием данных;
· защитой данных паролем;
· ограничением доступа к базе данных (к таблице, к словарю и т.д.).
Обеспечение целостности данных подразумевает наличие средств, позволяющих удостовериться, что информация в базе данных всегда остается корректной и полной. Целостность данных должна обеспечиваться независимо от того, каким образом данные заносятся в память (в интерактивном режиме, посредством импорта или с помощью специальной программы). Используемые в настоящее время СУБД обладают средствами обеспечения целостности данных и надежной безопасности.
Система управления базами данных управляет данными во внешней памяти, обеспечивает надежное хранение данных и поддержку соответствующих языков базы данных. Важной функцией СУБД является функция управления буферами оперативной памяти. Обычно СУБД работают с базами данных больших размеров, часто превышающими размеры оперативной памяти ЭВМ. В развитых СУБД поддерживается свой набор буферов оперативной памяти с собственной дисциплиной их замены.
Наибольшее распространение в настоящее время получили системы управления базами данных Microsoft Access и Oracle.
Этапами работы в СУБД являются:
· создание структуры базы данных, т.е. определение перечня полей, из которых состоит каждая запись таблицы, типов и размеров полей (числовой, текстовый, логический и т.д.), определение ключевых полей для обеспечения необходимых связей между данными и таблицами;
· ввод и редактирование данных в таблицах баз данных с помощью представляемой по умолчанию стандартной формы в виде таблицы и с помощью экранных форм, специально создаваемых пользователем;
· обработка данных, содержащихся в таблицах, на основе запросов и на основе программы;
· вывод информации из ЭВМ с использованием отчетов и без использования отчетов.
Реализуются названные этапы работы с помощью различных команд.
Централизованная база данных обеспечивает простоту управления, улучшенное использование данных на местах при выполнении дистанционных запросов, более высокую степень одновременности обработки, меньшие затраты на обработку.
Распределенная база данных предполагает хранение и выполнение функций управления данными в нескольких узлах и передачу данных между этими узлами в процессе выполнения запросов. В такой базе данных не только различные ее таблицы могут храниться на разных компьютерах, но и разные фрагменты одной таблицы. При этом для пользователя не имеет значения как организовано хранение данных, он работает с такой базой, как с централизованной.
1.3.Модели описания баз данных
Известны три типа моделей описания баз данных – иерархическая, сетевая и реляционная, основное различие между которыми состоит в характере описания взаимосвязей и взаимодействия между объектами и атрибутами базы данных.
Иерархическая модель предполагает использование для описания базы данных древовидных структур, состоящих из определенного числа уровней. «Дерево» представляет собой иерархию элементов, называемых узлами. Под элементами понимается список, совокупность, набор атрибутов, элементов, описывающих объекты.
Эта статья содержит краткие сведения о базах данных: что это, чем они могут быть полезны, каковы функции их отдельных элементов. Здесь используется терминология, свойственная Microsoft Access, однако описываемые понятия применимы по отношению к любым базам данных.
В этой статье:
Что представляет собой база данных?
Базы данных - это инструмент для сбора и структурирования информации. В базе могут храниться данные о людях, товарах, заказах и о многом другом. Многие базы данных изначально представляют собой небольшой список в текстовом редакторе или электронной таблице. По мере увеличения объема данных в списке постепенно появляются несоответствия и излишняя информация. Информация, отображенная в виде списка, становится непонятной. Кроме того, ограничены способы, с помощью которых можно искать и отображать подмножества данных. Как только начинают появляться эти проблемы, мы рекомендуем перенести всю информацию в базу данных, созданную в системе управления базами данных (СУБД), такой как Access.
Компьютерная база данных - это хранилище объектов. В одной базе данных может быть больше одной таблицы. Например, система отслеживания складских запасов, в которой используются три таблицы, - это не три базы данных, а одна. В базе данных Access (если ее специально не настраивали для работы с данными или кодом, принадлежащими другому источнику) все таблицы хранятся в одном файле вместе с другими объектами, такими как формы, отчеты, макросы и модули. Для файлов баз данных, созданных в формате Access 2007 (который также используется в Access 2016, Access 2013 и Access 2010), используется расширение ACCDB, а для баз данных, созданных в более ранних версиях Access, - MDB. С помощью Access 2016, Access 2013, Access 2010 и Access 2007 можно создавать файлы в форматах более ранних версий приложения (например, Access 2000 и Access 2002–2003).
Использование Access позволяет:
добавлять новую информацию в базу данных, например новый артикул складских запасов;
изменять информацию, уже находящуюся в базе, например перемещать артикул;
удалять информацию, например если артикул был продан или утилизирован;
упорядочивать и просматривать данные различными способами;
обмениваться данными с другими людьми с помощью отчетов, сообщений электронной почты, внутренней сети или Интернета.
Элементы базы данных Access
Ниже приведены краткие описания элементов стандартной базы данных Access.
Таблицы
Таблица базы данных похожа на электронную таблицу - и там, и там информация расположена в строках и столбцах. Поэтому импортировать электронную таблицу в таблицу базы данных обычно довольно легко. Основное различие заключается в том, как данные структурированы.
Чтобы база данных была как можно более гибкой и чтобы в ней не появлялось излишней информации, данные должны быть структурированы в виде таблиц. Например, если речь идет о таблице с информацией о сотрудниках компании, больше одного раза вводить данные об одном и том же сотруднике не нужно. Данные о товарах должны храниться в отдельной таблице, как и данные о филиалах компании. Этот процесс называется нормализацией .
Строки в таблице называются записями. В записи содержатся блоки информации. Каждая запись состоит по крайней мере из одного поля. Поля соответствуют столбцам в таблице. Например, в таблице под названием "Сотрудники" в каждой записи находится информация об одном сотруднике, а в каждом поле - отдельная категория информации, например имя, фамилия, адрес и т. д. Поля выделяются под определенные типы данных, например текстовые, цифровые или иные данные.
Записи и поля можно описать по-другому. Представьте старый библиотечный карточный каталог. Каждой карточке в шкафу соответствует запись в базе данных. Блоки информации на карточке (автор, название книги и т. д.) соответствуют полям в базе данных.
Дополнительные сведения о таблицах см. в статье Общие сведения о таблицах .
Формы
С помощью форм создается пользовательский интерфейс для ввода и редактирования данных. Формы часто содержат кнопки команд и другие элементы управления, предназначенные для выполнения различных функций. Можно создать базу данных, не используя формы, если просто отредактировать уже имеющуюся информацию в таблицах Access. Тем не менее, большинство пользователей предпочитает использовать формы для просмотра, ввода и редактирования информации в таблицах.
С помощью кнопок команд задаются данные, которые должны появляться в форме, открываются прочие формы и отчеты и выполняется ряд других задач. Например, есть "Форма клиента", в которой вы работаете с данными о клиентах. И в ней может быть кнопка, нажатием которой открывается форма заказа, с помощью которой вы вносите информацию о заказе, сделанном определенным клиентом.
Формы также дают возможность контролировать взаимодействие пользователей с информацией базы данных. Например, можно создать форму, в которой отображаются только определенные поля и с помощью которой можно выполнять только ограниченное число операций. Таким образом обеспечивается защита и корректный ввод данных.
Дополнительные сведения о формах см. в статье Формы .
Отчеты
Отчеты используются для форматирования, сведения и показа данных. Обычно отчет позволяет найти ответ на определенный вопрос, например "Какую прибыль в этом году принесли нам наши клиенты?" или "В каких городах живут наши клиенты?" Отчеты можно форматировать таким образом, чтобы информация отображалась в наиболее читабельном виде.
Отчет можно сформировать в любое время, и в нем всегда будет отображена текущая информация базы данных. Отчеты обычно форматируются таким образом, чтобы их можно было распечатать, но их также можно просматривать на экране, экспортировать в другие программы или вкладывать в сообщения электронной почты.
Запросы
Запросы могут выполнять множество функций в базе данных. Одна из их основных функций - находить информацию в таблицах. Нужная информация обычно содержится в нескольких таблицах, но, если использовать запросы, ее можно просматривать в одной. Кроме того, запросы дают возможность фильтровать данные (для этого задаются критерии поиска), чтобы отображались только нужные записи.
Используются и так называемые "обновляемые" запросы, которые дают возможность редактировать данные, найденные в основных таблицах. При работе с обновляемым запросом помните, что правки вносятся в основные таблицы, а не только в таблицу запроса.
Есть два основных вида запросов: запросы на выборку и на изменение. Запрос на выборку только находит данные и предоставляет к ним доступ. Результаты такого запроса можно просмотреть на экране, распечатать или скопировать в буфер обмена, а также использовать в качестве источника записей для формы или отчета.
С помощью запроса на изменение, как видно из названия, можно выполнять определенные операции с найденными данными: создавать таблицы, добавлять информацию в уже существующие таблицы, а также обновлять или удалять данные.
Дополнительные сведения о запросах см. в статье Знакомство с запросами .
Макросы
Макросы в Access - это нечто вроде упрощенного языка программирования, с помощью которого можно сделать базу данных более функциональной. Например, если к кнопке команды в форме добавить макрос, то он будет запускаться всякий раз при нажатии этой кнопки. Макросы состоят из команд, с помощью которых выполняются определенные задачи: открываются отчеты, выполняются запросы, закрывается база данных и т. д. Используя макросы, можно автоматизировать большинство операций, которые в базе данных вы делаете вручную, и, таким образом, значительно сэкономить время.
Дополнительные сведения о макросах см. в статье Общие сведения о программировании в Access .
Модули
Подобно макросам, модули - это объекты, с помощью которых базу данных можно сделать более функциональной. Но если макросы в Access составляются путем выбора из списка макрокоманд, модули создаются на языке Visual Basic для приложений (VBA). Модули представляют собой наборы описаний, инструкций и процедур. Существуют модули класса и стандартные модули. Модули класса связаны с конкретными формами или отчетами и обычно включают в себя процедуры, которые работают только с этими формами или отчетами. В стандартных модулях содержатся общие процедуры, не связанные ни с каким объектом. Стандартные модули, в отличие от модулей класса, перечисляются в списке Модули в области навигации.
Большинство баз данных имеют табличную структуру. Таблицы – основные объекты базы данных. В таблицах хранятся необработанные данные. Каждая таблица содержит записи определенного вида, например, о студентах, обучающихся в средних учебных заведениях.
Запись – полный набор данных об определенном объекте. В режиме таблицы запись изображается как строка.
Каждая запись таблицы содержит всю необходимую информацию об отдельном элементе базы данных. Например, запись о студенте может содержать номер его личного дела, фамилию, имя, отчество, пол, дату рождения, номер учебной группы. Такие отдельные структурные элементы записи таблицы называются полями. В режиме таблицы для представления поля используется столбец или ячейка, в этом случае имя поля является заголовком столбца таблицы.
Таким образом, поле – это наименьший поименованный элемент информации, хранящийся в базе данных и рассматриваемый как единое целое.
Структура базы данных – это набор полей, которые определяют содержание и вид БД. Она определяет методы занесения данных и хранения их в базе.
Термины база данных, таблица, запись, поле и значение указывает на иерархию от наибольшего элемента к наименьшему в базах данных Access.
Если в базе данных нет никаких данных, то это все равно полноценная база данных. Хотя данных в базе и нет, но информация в ней все-таки есть – это структура базы
Чтобы файл считался базой данных, информация в нем должна быть форматирована так, чтобы содержимое соседних полей легко различалось.
Первым этапом при создании таблицы является определение перечня полей, из которых она должна состоять, их типов и размеров.
Каждому полю таблицы присваивается уникальное имя, которое не может содержать более 64 символов, не разрешается использовать символы: “.”, “!”, “[”, “]”.
Тип поля указывает Access, как обрабатывать эти данные. Можно использовать следующие типы:
Текстовый – для текстовой информации и чисел при невыполнении математических расчетов (до 255 символов).
Поле МЕМО – для хранения произвольного текста, комментариев.
Числовой – при выполнении над данными математических операций.
Денежный – специальное числовое поле используется для операций с деньгами.
Дата/Время – предназначено для хранения информации о дате и времени.
Счетчик – специальное числовое поле, в котором Access автоматически присваивает уникальный порядковый номер каждой записи.
Логический – может иметь только одно из двух возможных значений “Да” или “Нет”.
Поле объекта OLE – объект, созданный другим приложением.
Базы данных, имеющие связанные таблицы по совпадающим значениям полей, называются реляционными. Большинство современных БД для персональных ЭВМ являются реляционными.
База данных в ACCESS представляет собой единый большой объект, который объединяет такие составляющие, как таблицы, отчеты, запросы, формы и т.д., и позволяет хранить их в едином дисковом файле.
Прежде, чем начать непосредственную работу по разработке базы данных, остановимся на характеристиках некоторых основных объектов базы данных.
Исходное окно Access отличается простотой и лаконичностью. Шесть вкладок этого окна представляют шесть видов объектов, с которыми работает программа.
Таблица – это основной объект базы данных, предназначенный для хранения данных в виде записей (строк) и полей (столбцов). Обычно каждая таблица используется для хранения сведений по одному конкретному вопросу.
Форма – объект Microsoft Access, предназначенный, в основном, для ввода данных. В форме можно разместить элементы управления, применяемые для ввода, изображения и изменения данных в полях таблиц.
Запрос – объект, позволяющий получить нужные данные из одной или нескольких таблиц.
Отчет – объект базы данных Microsoft Access, предназначенный для создания документа, который впоследствии может быть распечатан или включен в документ другого приложения.
Макросы – это макрокоманды (простые команды), предназначенные для автоматизации выполнения каких-то операций с базой без программирования.
Модули – это программные процедуры, написанные на языку VBasic.
Открытие базы данных делает ее объекты доступными для Access. С помощью вкладок можно выбрать тип нужного объекта.
Access может работать одновременно только с одной базой данных. Однако в одной базе данных Access могут содержаться сотни таблиц, форм, запросов, отчетов (все эти объекты хранятся в одном файле с расширением MBD).
Любая таблица Microsoft Access может быть представлена в двух режимах:
1) режиме конструктора, предназначенном для правки не содержимого, а устройства. Если это таблица, в нее можно вводить новые поля или изменять свойства существующих полей. Если это форма, в ней можно изменять или создавать элементы управления;
2) режиме таблицы, предназначенном для ввода данных, их просмотра и редактирования.
В созданную таблиц данные могут быть введены как непосредственно в табличной форме по умолчанию, так и с использованием специально разработанной пользовательской экранной формы. Редактирование записей и исправление ошибок в данных таблицы возможно также в каждом из двух указанных режимов.
При любом из указанных способов ввода и корректировки, данных таблицы Access сохраняет введенную или исправленную запись на диске (том, на котором создана таблица БД).
В режиме таблицы показ записей в формате строк и столбцов обеспечивает возможность одновременного просмотра нескольких записей. Допускается также добавление и изменение данных в режиме таблицы.
Вдоль верхнего края окна расположены имена полей таблицы. Каждое поле соответствует определенному столбцу в таблице. Каждая запись занимает одну строку таблицы. Ввод в определенную ячейку таблицы (выделенную курсором) осуществляется путем набора информации на клавиатуре и последующим нажатием клавиши Enter или Tab. При окончании ввода данных в последнее поле записи Access сам переходит на первое поле новой записи и ожидает ввода данных.
Предметной областью называется часть реальной системы, представляющая интерес для данного исследования. При проектировании автоматизированных информационных систем предметная область отображается моделями данных нескольких уровней. Число уровней зависти от сложности решаемых задач, но в любом случае включает концептуальный и логический уровни.
В данной дипломной работе предметной областью является работа интернет - кафе, которое предоставляет различные услуги для посетителей.
Администратор проводит записи на предоставление услуг и берёт оплату.
База данных предназначена для хранения данных о посетителях, компьютерах и услугах.
Спроектируем БД (рис. 3.1.1)
Рисунок 3.1.1 Диаграмма классов
Создадим базу данных с такими таблицами:
Администраторы;
Компьютеры;
Посетители;
3 Описание базы данных
Особую значимость для подсистемы составляют базы данных
База данных АИС – совокупность файлов, документов, показателей, данных, упорядоченных по определенным признакам, имеющим общие принципы описания, хранения и манипулирования данными, а также обеспечивающих их независимость от прикладных программ. В базе данных АИС может быть представлена не только экономическая, но и правовая, научная, техническая и другая информация. В основе классификации базы данных могут быть положены различные основания деления. В большинстве случаев выбор оснований систематизации базы данных определяется конкретными условиями работы предприятия и характером функциональных и информационных задач.
По форме представления данных различаются одноконтурные и многоконтурные базы данных. Основная форма представления базы данных двухконтурная. Могут быть и трехконтурные базы данных, когда третий контур представлен и сохраняется на традиционных бумажных документах. БД АИС четвертого контура может быть представлена в форме микрофильмированной ленты и ее отдельных отрезков.
По характеру содержащейся информации различают фактографические, документальные и смешанные базы данных. Фактографическая база данных отображает конкретные сведения, необходимые пользователю – факты, показатели, свойства продукции, формулы расчета какой-либо величины, отрывок (фрагмент) текста документа, документ полностью и др. Документальная БД содержит только сведения о документах – библиографическое описание документа, аннотацию, реферат, идентификатор документа, адрес его хранения в БД и т.д. Сам документ, как правило, во внешнем контуре БД – шкафу, хранилище, библиотеке-депозитарии. В документальных БД по массиву первого контура проводится поиск адреса хранения полного текста документа, а затем по адресу осуществляется доступ и к самому документу.
В смешанных БД представлены как фотографические, так и документальные массивы информации.
БД имеют определенные способы построения, так называемые модели баз данных: иерархические, сетевые, реляционные и объектно-ориентированные.
Иерархическая модель БД построена по принципу древовидного графа, в котором информационные элементы представлены по уровням их соподчиненности (иерархии). В структуре иерархии каждый порожденный узел не может иметь более одного порождающего (выходного) узла. Корень дерева здесь не порожденный, а порождающий узел. Узлы, не имеющие выхода, носят названия листьев. При поиске необходимых данных происходит чтение записей от корня к листьям дерева, т.е. сверху вниз. Достоинством стало то, что подобная структура БД обеспечивает более быстрый доступ и выдачу данных пользователю. Вместе с тем, недостатком представляется жесткость иерархической структуры. Отсутствует информационная гибкость в поиске, так как за один проход невозможно получить данные. В иерархической модели реализована связь между данными по схеме «один-ко-многим».
Сетевая модель БД имеет независимые типы данных, т.е. «Конкуренты», и зависимые типы данных – продукция и цены на продукцию. В сетевых моделях возможны как прямые, так и обратные виды связей между данными (записями). Существует ограничение – каждая связь должна включать в себя основную и зависимую записи. К достоинству сетевой модели можно отнести гибкость организации и доступа к данным относительно иерархической модели. Как недостаток можно указать, что сохраняется относительная жесткость в построении структуры БД. Это влечет необходимость в определенных ситуациях реструктурирования БД, препятствует реализации более гибкой стратегии поиска данных.
Реляционная модель БД имеет независимую организацию взаимосвязи логических и физических записей. Отношения между данными построены в виде двухмерных таблиц и наделены определенными признаками. Каждый элемент таблицы отображает одно данное. Элементы столбца таблицы имеют одинаковую природу, отображая одно свойство (признак) в строке (записи)таблицы.
Объектно-ориентированная модель БД – пример реализации БД более высокого логического уровня. ООБД возникли на концептуальной основе ООП. В отличие от структурного, ООП базируется на процедурных (программных) категориях (циклы, декларации, условия и др.), а на более широкой категории – объектах.
Организация ООБД имеет несколько стадий:
1) концептуальная модель, когда множество объектов БД прошли описание по соответствующим правилам;
2) логическая модель, когда определены свойства объектов и указаны логические взаимосвязи между объектами;
3) физическая модель, когда определены адреса и проведено размещение объектов в памяти ЭВМ
В структуру БД АИС входят различные компоненты – агрегаты, массивы, файлы и др. Агрегат – структурированная совокупность информационных объектов, определяемая как единый тип данных.
Массив информации – это поименованная совокупность однотипных (логически однородных) элементов, упорядоченных по индексам, которые определяют положение элементов в массиве
Файл – опорный структурный элемент БД Файл – поименованная область внешней памяти ЭВМ. Он может содержать различную информацию: текстовый документ, рисунок, музыкальное произведение, программу ЭВМ и др..
Расчета премии. Рис. 3.4 – Диаграмма IDEF3. Основные элементы модели представлены в таблицах 3.4 – 3.6. Таблица 3.4. Основные элементы модели Название проекта: Проектирование ИС для расчета оплаты труда в торговле Цель проекта: реализация структурной функциональной модели ИС Технология моделирования: метод описания бизнес-процессов IDEF3 Инструментарий: программный продукт BPwin ...
Начисленные в текущем месяце – ОПВ за текущий месяц – Сумма ИПН, подлежащая удержанию. ЗАКЛЮЧЕНИЕ В данной дипломной работе, при проектировании информационной системы «Начисление заработной платы сотрудникам школы» были рассмотрены принципы проектирования концептуальной модели, логической модели и были рассмотрены основные причины, по которым данный выбор программного обеспечения Delphi был...
Рисунок 5 – Диаграмма классов 3 Описание проблем и формирование концепции информационной системы 3.1 Проблемы предметной области После проведения исследования предметной области были выявлены следующие проблемы: − с увеличением количества пациентов сети поликлиник, увеличивается количество информационных потоков, что приводит к снижению управляемости...
Информационных технологий на деятельность организации. 2. Создание логической модели ЕСВ Нашей первой задачей является создание логической модели информационной системы единой среды взаимодействия студентов для образования полноценного научно-образовательного сообщества. Основным концептуальным понятием общей модели системы мы выбрали процессы. Процессы: · учебная работа · научная...
Построение реляционных баз данных
Основы построения реляционных баз данных
Описание реляционных данных
В процессе построения реляционной базы данных должны быть решены несколько задач. Во-первых, необходимо описать структуру базы данных для СУБД. Для этого разработчик использует язык описания данных или какой-либо эквивалентный способ описания структуры (например, графическое отображение). Затем база данных записывается на тот или иной физический носитель и заполняется данными. В этом разделе мы рассмотрим каждую из этих задач, но сначала познакомимся с реляционной терминологией.
Обзор терминологии
Как указывалось в главе 5, отношение - это таблица, обладающая определенными свойствами.
Записи в отношении могут иметь только одиночные значения; множественные значения не допускаются. Следовательно, на пересечении строки и столбца находится только одно значение.
Все записи в одном столбце имеют один и тот же тип. Например, один столбец может содержать имена покупателей, а другой - их даты рождения. Каждый столбец имеет уникальное имя, и порядок следования столбцов несуществен. Столбцы отношения носят название атрибутов. Каждый атрибут имеет свой домел, который представляет собой физическое и логическое описание множества допустимых значений.
3. В отношении не может быть двух одинаковых строк, и порядок следования строк несуществен (рис. 8.1). Строки отношения называются также кортежами.
Рисунок 8.1 являет собой пример, или отдельный экземпляр, реляционной структуры, содержащей сведения о пациенте клиники. Обобщенный формат, PATIENT (Name , Birth Date , Gender , AccountNumber , Physician ) - это структура отношения; именно ее большинство людей имеют в виду под термином отношение. (Вспомните из главы 5, что подчеркиванием выделяется атрибут, являющийся ключом отношения.) Если мы добавим в структуру отношения ограничение на возможные значения данных, мы получим реляционную схему (relational schema). Все эти термины приведены в табл. 8.1.
Недоразумения относительно термина «ключ»
Термин ключ зачастую является источником недоразумений, так как он имеет различные значения на стадиях проектирования и реализации. В процессе проектирования под ключом понимается один или несколько столбцов, однозначно определяющих строку отношения. Как мы знаем из главы 5, каждое отношение имеет хотя бы один ключ, поскольку каждая строка является уникальной; в предельном случае ключ представляет собой комбинацию всех столбцов отношения. Обычно ключ состоит из одного-двух столбцов.
На стадии реализации термин ключ используется в другом значении. В большинстве реляционных СУБД ключом называется столбец, на базе которого СУБД формирует индекс и другие структуры данных. Это делается для того, чтобы обеспечить быстрый доступ к значениям из данного столбца. Эти ключи не обязаны быть уникальными, и зачастую они действительно таковыми не являются. Они создаются только для повышения быстродействия. (Информацию о таких структурах данных вы найдете в приложении А.)
Рассмотрим, например, отношение ЗАКАЗ (НомерЗаказа, ДатаЗаказа, НомерКли-ента, Количество). С точки зрения проектирования, ключом этого отношения является НомерЗаказа, так как выделение жирным шрифтом означает, что данный атрибут однозначно определяет строку отношения. С точки зрения реализации, ключом может быть любой из четырех столбцов данного отношения. Это может быть, например, атрибут ДатаЗаказа. В таком случае СУБД создаст структуру данных, обеспечивающую быстрый доступ к данным из отношения ЗАКАЗ по значению даты заказа. Скорее всего, конкретному значению атрибута ДатаЗаказа будет соответствовать много строк. В данном смысле определение атрибута в качестве ключа не говорит ничего о его уникальности.
Иногда, чтобы различать два значения слова ключ, употребляются термины логический ключ (logical key) и физический ключ (physical key). Логический ключ - это уникальный идентификатор, а физический ключ - это столбец, для которого с целью увеличения быстродействия создан индекс или другая структура данных.
Индексы
Поскольку физический ключ обычно является индексом, некоторые оставляют за термином ключ значение логического ключа, а за термином индекс - значение физического ключа. В данной книге мы именно так и будем поступать: термин ключ мы будем использовать в значении «логический ключ», а термин индекс - в значении «физический ключ».
В пользу создания индексов есть три соображения. Одно из них состоит в том, чтобы обеспечить ускоренный доступ к строкам по значению индексируемого атрибута. Другое заключается в упрощении сортировки строк по этому атрибуту. Например, в отношении ЗАКАЗ в качестве ключа может быть определен атрибут ДатаЗаказа, в результате чего отчеты, в которых заказы отсортированы по дате, будут генерироваться быстрее.
Третья цель построения индексов - обеспечение уникальности. Индексы не обязаны быть уникальными, но когда разработчик хочет, чтобы какой-то столбец был уникальным, СУБД создает для этого столбца индекс. В большинстве реляционных СУБД столбец или группу столбцов можно сделать уникальными, если при определении столбца в таблице указать ключевое слово UNIQUE .
Реализация реляционной базы данных
И этой книге для описания структуры базы данных мы используем реляционную модель. Поэтому от проектирования базы данных мы можем непосредственно переходить к ее реализации. Нам нет нужды как-либо преобразовывать структуру па стадии реализации: все, что требуется сделать, - это описать существующую реляционную структуру для СУБД.
При реализации баз данных с использованием СУБД, основанных не на реляционной модели, дело обстоит иначе. Например, реализуя базу данных на основе модели DL/I, мы должны преобразовать реляционную структуру в иерархическую, а затем описать для СУБД преобразованную структуру.
Описание структуры базы данных для СУБД
Есть несколько способов, с помощью которых структура базы данных описывается для СУБД. Эти способы зависят от того, какая конкретно СУБД используется. 13 некоторых продуктах создается текстовый файл, который описывает структуру базы данных. Язык, используемый для определения такой структуры, иногда называется языком определения данных (data definition language, DDL). В текстовом DDL-файле перечислены названия таблиц базы данных, указаны названия столбцов этих таблиц и описано их содержимое, определены индексы, а также описаны другие структуры (ограничения, меры безопасности). В листинге 8.1 с помощью типичного языка определения данных описана простая реляционная база данных для гипотетической СУБД. Более реалистичные примеры с использованием стандарта под названием SQL приведены в главах 12 и 13.
Некоторые СУБД не требуют, чтобы структура базы данных была определена с помощью DDL в текстовом формате. Наиболее распространенная альтернатива - это графический способ задания структуры базы данных. Например, в Access 2002 разработчику дается графическая структура в виде списка, в соответствующих местах которой нужно ввести имена таблиц и столбцов. Пример этого мы видели в главе 2 (см. рис. 2.2).
Вообще говоря, графические средства описания данных распространены в СУБД, предназначенных для работы на персональных компьютерах. На серверах и больших ЭВМ применяются как графические, так и текстовые средства. Например, в Oracle и SQL Server для определения данных могут применяться оба способа. На рис. 8 .2 представлена общая схема процесса описания данных для СУБД.
При любом способе определения структуры данных разработчик должен дать название каждой таблице, определить столбцы для этой таблицы и описать физический формат данных в каждом столбце (скажем, TEXT 10). Кроме того, в зависимости от возможностей используемой СУБД, разработчик может указать ограничения, которые должны реализовываться СУБД. Значения столбцов могут определяться, например, как NOT NULL (не пустой) или UNIQUE (уникальный). Некоторые продукты позволяют также устанавливать ограничения на возможные значения (атрибут Часть может принимать значения, меньшие 10 000, а атрибут Цвет может принимать одно из значений ["Красный"/Зеленый"/Синий"]). Наконец, могут быть введены ограничения целостности по внешнему ключу. Приведем пример такого ограничения: «Значение атрибута НомерОтдела в таблице СОТРУДНИК должно быть равно значению атрибута НомерОтдела в таблице ОТДЕЛ».
Во многих СУБД разработчик может также устанавливать пароли и использовать другие средства контроля и безопасности. Как будет показано в главе 11, существует множество различных стратегий обеспечения безопасности. В одних стратегиях объектами контроля являются структуры данных (например, таблица защищается паролем), в других - пользователи (обладатель пароля X может читать и обновлять таблицы Т1 и Т2).
Распределение пространства на физических носителях
Кроме определения структуры базы данных, разработчик должен выделить место для базы данных на физическом носителе. И вновь конкретные действия зависят от того, какая именно СУБД используется. В случае персональной базы данных псе, что требуется сделать, - это присвоить базе данных каталог на диске и дать ей имя. После этого СУБД автоматически выделит пространство для хранения данных.
Другие СУБД, в особенности предназначенные для серверов и больших ЭВМ, требуют больших усилий. Чтобы повысить быстродействие и улучшить контроль, необходимо тщательно спроектировать распределение информации в базе данных по дискам и каналам. Например, в зависимости от специфики обработки приложений, может оказаться, что определенные таблицы лучше размещать на одном и том же диске. И наоборот, может быть важно, чтобы определенные таблицы не находились на одном и том же диске.
Рассмотрим, например, объект-заказ, скомпонованный из таблиц ЗАКАЗ, СТР0КА_ ЗАКАЗА и ТОВАР. Предположим, что при обработке заказа приложение считывает одну строку из таблицы ЗАКАЗ, несколько строк из таблицы СТР0КА_ЗАКАЗА и по одной строке из таблицы ТОВАР для каждой строки из таблицы СТР0КА_ЗАКАЗА. Далее, строки из таблицы СТР0КА_ЗАКАЗА, относящиеся к одному и тому же заказу, обычно сгруппированы вместе, а строки в таблице ТОВАР не сгруппированы никак. Эту ситуацию иллюстрирует рис. 8.3.
Теперь представим, что организация параллельно обрабатывает множество заказов и что у нее есть два диска: один большого объема и быстродействующий, а другой - меньшего объема и более медленный. Разработчик должен определить наилучшее место для хранения данных. Возможно, производительность улучшится, если таблица ТОВАР будет храниться на большом диске с быстрым доступом, а таблицы СТРОКА_ЗАКАЗА и ЗАКАЗ - на диске меньшего размера и быстродействия. А может быть, производительность будет выше, если поместить данные из таблиц ЗАКАЗ и СТРОКА_ЗАКАЗА за предыдущие месяцы на более медленный диск, а за текущий месяц - на более быстрый.
Мы не можем ответить на эти вопросы здесь, поскольку ответ зависит от объема данных, характеристик СУБД и операционной системы, размера и быстродействия дисков и каналов, а также от требований приложений, использующих эту базу данных. Смысл состоит в том, что все эти факторы необходимо принимать во внимание при выделении пространства для базы данных на физическом носителе.
Кроме местоположения и объема пространства для данных пользователя, разработчику, возможно, потребуется также указать, должно ли это пространство увеличиваться по мере необходимости, и если да, то на какую величину. Как правило, величина такого приращения указывается либо в виде фиксированного значения, либо в виде процентов от первоначального объема занимаемого пространства.
При создании базы данных разработчику понадобится выделить файловое пространство для журналов базы данных. О ведении журналов вы узнаете в главах 11-13; на данном этапе вам просто следует знать, что СУБД ведет журнал изменений в базе данных, который потом, в случае необходимости, можно использовать для восстановления базы. Файловое пространство для журналов выделяется на этапе создания базы данных.
Составление плана обслуживания базы данных
План обслуживания (maintenance plan) базы данных - это расписание процедур, которые необходимо выполнять на регулярной основе. Эти процедуры включают в себя резервное копирование базы данных, сброс содержимого журнала базы данных в архивные файлы, проверка на наличие нарушений ссылочной целостности, оптимизация дискового пространства для данных пользователя и индексов и т. д. К этим вопросам мы также обратимся в главе 11, но имейте в виду, что план обслуживания базы данных должен составляться в процессе ее создания или вскоре после него.
Заполнение базы данных информацией
Когда база данных описана и для ее хранения выделено пространство на физическом носителе, можно начинать заполнение базы данных информацией. То, каким путем это делается, зависит от требования приложений и возможностей СУБД. В лучшем случае все данные уже находятся в формате, воспринимаемом компьютером, а в СУБД имеются возможности и средства, позволяющие упростить импорт данных с магнитных носителей. В худшем случае все данные должны вводиться вручную через клавиатуру с помощью прикладных программ, созданных разработчиками «с нуля». Большинство ситуаций, где необходимо конвертирование данных, находятся в промежутке между этими двумя крайними случаями.
Когда данные введены, необходимо проверить их корректность. Такая проверка утомительна и требует больших трудозатрат, однако она весьма важна. Зачастую, особенно в больших базах данных, есть смысл в написании специальных программ для проверки данных. Преимущества от использования этих программ вполне окупят время и деньги, затраченные командой разработчиков на их создание. Такие программы занимаются тем, что подсчитывают количество строк в различных категориях, вычисляют контрольные суммы, выполняют проверки допустимости значений данных и другие процедуры контроля.
Манипулирование реляционными данными
Мы обсудили проектирование реляционных баз данных и способы, при помощи которых структура базы данных описывается для СУБД. До сих пор, говоря об операциях с отношениями, мы рассуждали в обобщенной и интуитивной манере. Такая манера хороша, пока речь идет о проекте, но для реализации приложений нам нужен четкий и непротиворечивый язык, выражающий логику обработки. Такие языки носят название языков манипулирования данпьши (data manipulation languages, DML).
На сегодняшний день предложено четыре стратегии манипулирования реляционными данными. Первая из стратегий, реляционная алгебра (relational algebra), определяет операторы, действующие на отношения (они подобны операторам высшей алгебры +, - и т. д.). Эти операторы позволяют манипулировать отношениями для достижения желаемого результата. Но реляционная алгебра трудна в использовании, отчасти потому, что она является процедурной. Это значит, что при использовании реляционной алгебры мы должны знать не только то, что мы делаем, но и то, как это делается.
Реляционная алгебра не используется в коммерческих системах обработки баз данных. Хотя ни одна коммерчески успешная СУБД не включает в себя инструментарий реляционной алгебры, мы будем обсуждать ее здесь, поскольку это поможет яснее представить себе манипулирование реляционными данными и заложит основу для изучения SQL.
Реляционное исчисление (relational calculus) - вторая стратегия манипулирования реляционными данными. Реляционное исчисление не является процедурным; оно представляет собой язык, выражающий то, что мы хотим сделать, без указания на то, как этого достичь. Вспомните переменную интегрирования в интегральном исчислении: эта переменная принимает значения из того диапазона, по которому происходит интегрирование. В реляционном исчислении есть подобная переменная. В кортежио-реляционном исчислении областью значений этой переменной являются кортежи отношения, а в доменно-реляционном исчислении - значения домена. В основе реляционного исчисления лежит область математики, называемая исчислением предикатов.
Если вы не собираетесь становиться теоретиком реляционной технологии, вам, скорее всего, не понадобится изучать реляционное исчисление. Оно никогда не используется в коммерческих системах обработки баз данных, и в его изучении для наших целей нет необходимости. Таким образом, мы не будем обсуждать его в этой книге.
Хотя реляционное исчисление трудно для понимания и использования, его непроцедурный характер является преимуществом. Поэтому разработчики СУБД начали поиск других непроцедурных стратегий, который привел к появлению третьей и четвертой категорий языков манипулирования реляционными данными.
Языки, ориентированные на преобразования (transform-oriented languages), - это класс непроцедурных языков, которые преобразуют входные данные, имеющие вид отношений, в результат, представляющий собой одно отношение. В этих языках имеются простые в использовании структуры, позволяющие указать действия, которые необходимо совершить с предоставленными данными. SQUARE, SEQUEL и SQL - это примеры языков, ориентированных на преобразования. Язык SQL будет подробно изучаться нами в главах 9, 12 и 13.
Четвертая категория языков манипулирования реляционными данными - это графические языки. К этой категории относятся запрос по образцу (Query-by-Example) и запрос из формы (Query-by-Form). В числе продуктов, поддерживающих эту категорию, можно упомянуть Approach (фирмы Lotus) и Access. Пользователю выдается графическое представление одного отношения или более. Представление может иметь вид формы для ввода данных, электронной таблицы или какой-либо другой структуры. СУБД преобразует представление в соответствующее отношение и формирует запросы (скорее всего, на SQL) от лица пользователя. После этого пользователи инициируют выполнение операторов DML, по они об этом не знают. Четыре категории языков манипулирования реляционными данными:
реляционная алгебра;
реляционное исчисление;
языки, ориентированные на преобразования (например, SQL);
запрос по образцу, запрос из формы.
Интерфейсы языков манипулирования данными
В этом разделе мы рассмотрим четыре вида интерфейсов, с помощью которых осуществляется манипулирование информацией в базе данных.
Манипулирование данными посредством форм
В большинстве реляционных СУБД имеются средства для создания форм. Некоторые формы генерируются автоматически при определении таблицы, другие должны создаваться разработчиком. Помощь в этом процессе может оказать интеллектуальный ассистент, присутствующий, например, в Access. Форма может иметь вид таблицы (электронной таблицы), в которой одновременно показываются несколько строк отношения. Есть и другой вид форм, где каждая строка отношения представляется отдельно. На рис. 8.4 и 8.5 приведены примеры обоих типов форм для таблицы PATIENT с рис. 8.1. Большинство продуктов обеспечивают некоторую гибкость в обработке форм и отчетов. Например, строки для обработки могут выбираться по значениям столбцов и могут быть отсортированы. Таблица па рис. 8.4 отсортирована по значению поля AccountNumber.
Многие формы, генерируемые по умолчанию, содержат в себе данные только из одного отношения. Если нужно получить данные из двух или более отношений, тогда, как правило, нужно создавать специальные формы с помощью средств СУБД. Такие средства позволяют создавать как многотабличные, так и многострочные формы. Поскольку использование этих средств сильно зависит от конкретной СУБД, мы не будем рассматривать их далее.
Интерфейс языка запросов и обновлений
Второй тип интерфейса к базе данных - это язык запросов и обновлений (query/ update language), или просто язык запросов (query language). (Хотя большинство такого рода языков позволяют выполнять как запрос, так и обновление данных, их чаще всего называют языками запросов.) В этом случае пользователь вводит команды, которые указывают, какие действия необходимо произвести над базой данных. СУБД расшифровывает эти команды и выполняет предписанные действия. Рисунок 8.6 показывает, какие программы участвуют в обработке запроса.
Важнейшим из всех языков запросов является SQL. Чтобы дать вам представление о языках запросов, рассмотрим следующий SQL-оператор, который обрабатывает отношение PATIENT , показанное на рис. 8.1:
SELECT Name. DateOfBirth FROM PATIENT
WHERE Physician = "Levy"
Этот оператор извлекает из отношения PATIENT все строки, в которых атрибут Physician имеет значение " Levy ". Значения атрибутов Name и DateOf Birth из этих строк он затем помещает во вторую таблицу.
Хранимые процедуры
Со временем пользователи и разработчики баз данных обнаружили, что некоторые последовательности команд SQL приходится выполнять регулярно. Единственное, что при этом меняется, - это значения, указываемые в предложении WHERE . Например, при ежемесячном начислении платежей выполняются одни и те же SQL-операторы, но с различной датой закрытия. Чтобы учесть эту потребность, производители СУБД ввели так называемые хранимые процедуры (stored procedures). Такая процедура представляет собой набор SQL-операторов, который хранится в файле и может быть запущен на выполнение одной командой. Параметры, указываемые в предложении WHERE и т. д., могут передаваться при вызове процедуры. Примером может служить следующее:
DO BILLING STORED_PROCEDURE FOR BILLDATE = "9/1/2000"
Эта строка запускает хранимую процедуру под названием BILLING со значением параметра BILLDATE , равным "9/1/2000".
По мере накопления разработчиками опыта выявилась одна проблема. SQL создавался как подъязык данных, и при этом не делалось попыток наделить его всеми элементами полноценного языка программирования. Однако некоторые из этих элементов были необходимы для написания хранимых процедур, и производители СУБД создали расширенные версии SQL, включив в них дополнительные возможности. Один такой язык, PL/SQL, был разработан для Oracle, а еще один, под названием TRANSACT-SQL, - для SQL Server. Более подробно об этих языках вы узнаете из глав 12 и 13.
Специальный тип хранимой процедуры - триггер (trigger) - вызывается СУБД при выполнении заданного условия. Например, в приложении, обрабатывающем заказы, разработчик должен создать триггер, который запускается в тех случаях, когда количество товара на складе оказывается ниже заданного предела (то есть пора заказывать товар у оптового поставщика). Более подробно о хранимых процедурах вы узнаете из глав 12 и 13.
Интерфейс прикладных программ
Четвертый тип интерфейса доступа к данным - это доступ через прикладные программы, написанные на таких языках программирования, как COBOL, BASIC, Perl, Pascal и С++. Кроме того, некоторые прикладные программы пишутся на встроенных в используемые СУБД языках. Из таких языков программирования наибольшей известностью пользуется dBASE.
Есть два стиля интерфейса между прикладными программами и СУБД. Первый из них характеризуется тем, что прикладные программы вызывают подпрограммы из библиотеки функций, поставляемой в комплекте с СУБД. Например, чтобы считать строку из таблицы, прикладная программа вызывает функцию чтения СУБД и передает ей параметры, которые указывают нужную таблицу, требуемые столбцы, критерии выбора строки и т. п.
В некоторых случаях вместо вызовов функций используется объектно-ориентированный синтаксис. В приведенном ниже коде Access объектный указатель db устанавливается на открытую в данный момент базу данных, а объектный указатель rs ссылается на строки таблицы PATIENT ;
set db = currentdbC)
set rs = db.OpenRecordsetCPATIENT")
С помощью последнего указателя можно обращаться к свойствам откры того набора записей и запускать его методы. Например, с помощью свойства rs . AllowDeletions можно определить, могут ли быть удалены записи из набора записей PATIENT . Метод MoveFirst перемещает курсор на первую строку.
Второй, более старый тип интерфейса используется иногда в СУБД, предназначенных для больших ЭВМ и серверов. Здесь производителем СУБД определен набор высокоуровневых команд доступа к данным. Эти команды, которые относятся к обработке базы данных и не являются частью какого-либо стандартного языка, встраиваются в код прикладной программы.
Прикладная программа со встроенными командами передается на предварительный компилятор, входящий в комплект СУБД. Он транслирует операторы доступа к данным в корректные вызовы функций и определяет области данных, которые будут совместно использоваться прикладными программами и СУБД. Предварительный компилятор также вставляет в программу код, поддерживающий доступ к этим областям данных. Обработанная таким образом программа передается на языковой компилятор. На рис. 8 .7 показано взаимодействие программ в этом процессе.
