Основы информационных систем. Базы данных. Системы управления базами данных. Проектирование СУБД

Размещено на http://www.allbest.ru/

2

Основы информационных систем. Базы данных. Системы управления базами данных. Проектирование СУБД

Содержание

1. Основные понятия

2. Классификация БД

3. Модели данных

4. Проектирование баз данных

5. Литература

1. Основные понятия

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

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

Второе направление связано с использованием вычислительной техники для создания, хранения и обработки больших массивов данных. Такие задачи решают информационные системы (в дальнейшем -- ИС). К ним относятся поисковые, справочные, банковские системы, автоматизированные системы управления предприятием.

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

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

· ввод данных об объектах некоторой предметной области;

· надежное хранение и защита данных во внешней памяти вычислительной системы;

· дополнение, удаление, изменение данных;

· сортировка, выборка данных по запросам пользователей;

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

· предоставление пользователям удобного интерфейса;

· обобщение данных и составление отчетов.

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

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

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

2. Классификация БД

По технологии обработки данных БД подразделяются на централизованные и распределенные.

· Централизованная хранится целиком в памяти одной вычислительной системы. Если система входит в состав сети, то возможен доступ к этой БД других систем.

· Распределенная БД состоит из нескольких, возможно пересекающихся или дублирующих друг друга БД, хранимых в памяти разных вычислительных систем, объединенных в сеть.

По способу доступа к данным БД распределяются на локальный и удаленный (сетевой) доступ.

· Локальный доступ предполагает, что СУБД обрабатывает БД, которая хранится на том же компьютере.

· Удаленный доступ это обращение к БД, которая хранится на одном из компьютеров, входящих в компьютерную сеть Удаленный доступ может быть выполнен по принципу файл-сервер или клиент-сервер.

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

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

3. Модели данных

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

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

Каждая реляционная таблица должна обладать следующими свойствами:

· один элемент таблицы -- один элемент данных;

· все столбцы таблицы содержат однородные по типу данные (целочисленный, числовой, текстовый, и т.д.);

· каждый столбец имеет уникальное имя;

· число столбцов задается при создании таблицы;

· порядок записей в отношении может быть произвольным;

· записи не должны повторяться;

· количество записей в отношении не ограничено.

Объекты, их взаимосвязи и отношения представлены в виде таблиц. Формальное построение таблиц связано с фундаментальным понятием отношение (термин реляционная исходит от английского слова relation -- отношение).

Для заданных произвольных конечных множеств М1, М2, ..., Mn множество всевозможных наборов вида (µ1, µ2, ..., µ n), где µ1М1, µ1М1, µnМn, называют их декартовым произведением M1 Ч M2 Ч … Ч Mn. Отношением R, определенным на множествах М1, М2, ... , Mn, называется подмножество декартова произведения M1 Ч M2 Ч … Ч Mn. При этом множества М1, М2, ... , Mn называются доменами отношения, а элементы декартова произведения -- кортежами отношения. Число n определяет степень отношения, количество кортежей -- его мощность.

В реляционной таблице каждый столбец есть домен (его альтернативное название поле), а совокупность элементов каждой строки -- кортеж (или запись).

Строка заголовков называется схемой отношения. Например, схема отношения СТУДЕНТ может быть следующей:

СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА), здесь СТУДЕНТ - отношение, а ФАМИЛИЯ, ИМЯ и т.д. - атрибуты.

В отношении каждый конкретный экземпляр сущности представляется строкой, которая называется кортежем (или записью).

Первичным ключом отношения называется поле или группа полей, однозначно определяющие запись. В отношении СТУДЕНТ первичным ключом может быть поле ФАМИЛИЯ, если во всем списке нет однофамильцев -- это будет простой ключ. Если есть однофамильцы, то совокупность полей -- фамилия, имя, отчество -- создадут составной первичный ключ. На практике обычно в качестве ключевого выбирают поле, в котором совпадения заведомо исключены.

Для рассматриваемого примера таким полем может служить номер зачетной книжки студента.

Свойства первичного ключа:

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

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

• в состав первичного ключа не должны входить поля типа, комментарий и графическое.

Чтобы избежать повторяющихся записей, приходят к связыванию таблиц. Например, если в отношении СТУДЕНТ надо описать вуз, в котором он обучается, то, на первый взгляд, можно было бы включить в отношение следующие поля СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА, НАЗВАНИЕ вуза, АДРЕС). Но при заполнении такой таблицы для каждого студента придется указывать довольно длинное наименование вуза и его адрес, что неудобно. Более того, любая незначительная ошибка во вводе этих полей приведет к нарушению непротиворечивости базы данных. Например, ошибка в адресе вуза приведет к тому, что в БД появятся два вуза с одинаковым наименованием и разными адресами. Поступают в таком случае так: в отношение СТУДЕНТ вводят поле «код вуза» (целое число) и добавляют еще одно отношение ВУЗ (код вуза, название, адрес). СТУДЕНТ и ВУЗ при этом будут связаны по полю «код вуза».

При работе с такими таблицами повторяться могут только данные в поле «КОД вуза», а все необходимые сведения о вузе можно взять из отношения ВУЗ. Заметим при этом, что ввод в поле «КОД вуза» целого числа, вместо длинного названия, принесет гораздо меньше ошибок. В отношении ВУЗ поле «КОД вуза» будет первичным ключом, а в отношении СТУДЕНТ поле «КОД вуза» будет внешним ключом.

Для связи реляционных таблиц необходимо ввести в обе таблицы одинаковые по типу поля, по которым определится связь между записями обеих таблиц. Связи бывают нескольких типов «один к одному», «один ко многим», «многие ко многим». В вышеприведенном примере была установлена связь «один ко многим», т.е. одной записи в таблице ВУЗ соответствуют многие записи в таблице СТУДЕНТ.

4. Проектирование баз данных

база данные access информационная система

Проектирование базы данных является одним из этапов жизненного цикла ИС. Ввиду сложности этот этап выполняется, как правило, коллективом разработчиков и включает следующие работы:

• анализ предметной области;

• проектирование и непосредственно кодирование (создание запросов и приложений);

• тестирование и сопровождение.

Анализ предметной области

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

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

Проектирование баз данных осуществляется на двух уровнях - физическом и логическом. На физическом уровне решаются вопросы размещения данных на внешних носителях. Во многом эта работа выполняется СУБД автоматически без участия разработчика.

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

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

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

Вторая нормальная форма. Для приведения отношений ко второй нормальной форме, введем понятие функциональной зависимости.

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

Например, в отношении СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА) первичным ключом является совокупность полей ФАМИЛИЯ + ИМЯ + ОТЧЕСТВО. Поля ФАКУЛЬТЕТ, КУРС, ГРУППА функционально полно зависят от составного ключа.

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и каждое не ключевое поле функционально полно зависит от составного ключа. Например, в отношении УСПЕВАЕМОСТЬ (НОМЕР ЗАЧЕТКИ, ФАМИЛИЯ, ДИСЦИПЛИНА, ОЦЕНКА) составным ключом является совокупность НОМЕР ЗАЧЕТКИ + ДИСЦИПЛИНА. Это отношение находится в первой нормальной форме, но оно не находится во второй нормальной форме, так как поле ФАМИЛИЯ не имеет полной функциональной зависимости от составного ключа. Для перевода этого отношения во вторую нормальную форму необходимо исключить из него поле ФАМИЛИЯ, так как оно функционально зависит от НОМЕРА ЗАЧЕТКИ. Т.е. исходное отношение необходимо разбить на два связанных отношения УСПЕВАЕМОСТЬ (НОМЕР ЗАЧЕТКИ, ДИСЦИПЛИНА, ОЦЕНКА) и СПИСОК (НОМЕР ЗАЧЕТКИ, ФАМИЛИЯ). Связь здесь осуществляется по полю НОМЕР ЗАЧЕТКИ.

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

Например, в отношении СТУДЕНТ (ФАМИЛИЯ. ФАКУЛЬТЕТ, НАЗВАНИЕ вуза, АДРЕС) поле АДРЕС транзитивно (через поле НАЗВАНИЕ вуза) зависит от ключа ФАМИЛИЯ. При заполнении экземплярами такого отношения поле Адрес будет многократно повторяться. Для устранения транзитивной зависимости в классе используется расщепление отношения на несколько. Например, отношение СТУДЕНТ расщепляется на два:

СТУДЕНТ (ФАМИЛИЯ, ФАКУЛЬТЕТ, НАЗВАНИЕ вуза),

ВУЗ (НАЗВАНИЕ вуза, АДРЕС) связь по полю НАЗВАНИЕ вуза.

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

Проектирование

Дальнейшая работа над проектом связана с конкретной СУБД, поэтому, предварительно учитывая требования заказчика и намеченную архитектуру ИС, выбирают СУБД. Мы рассмотрим эту часть на примере СУБД MS Access (разработка Microsoft).

СУБД Access является системой управления базами данных реляционного типа. Всю базу данных по умолчанию Access хранит на диске в виде одного файла с расширением *.mdb, а вообще Access поддерживает ряд стандартов БД (dbase, Paradox и др.). Данные хранятся и виде таблиц, строки которых состоят из наборов полей определенных типов. С каждой таблицей могут быть связаны индексы (ключи), задающие нужные пользователю порядки на множестве строк. Таблицы могут иметь однотипные поля (столбцы), и это позволяет устанавливать между ними связи, выполнять операции реляционной алгебры.

Типичными операциями над базами данных являются:

• работа с таблицами (создание, модификация, удаление таблиц, создание и модификация схем взаимосвязи существующих таблиц);

• ввод данных в таблицы непосредственно или с помощью формы, проверку вводимых данных;

• поиск данных в таблицах по определенным критериям (выполнение запросов);

• создание отчетов о содержимом базы данных.

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

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

Создание таблиц предпочтительней в режиме конструктора. Здесь задаются имена полей и свойства, ниже находится редактор свойств полей, где указываются свойства (если поле текстовое -- его длина, числовое - тип целый или вещественный). Редактор свойств полей имеет скрытые элементы управления. Например, щелчок по полю ввода «размер поля» приведет к появлению элемента записи задается имя таблицы. Схема отношения может быть отредактирована путем повторного открытия ее в режиме конструктора. Далее определяются реляционные связи между таблицами, для чего открывается окно «Схема данных» нажатием кнопки [ ] в окне Access. В окне «Добавление таблицы» выбираем таблицы, которые окажет связать. Затем методом перетаскивания указываем связываемые поля, посте чего появляется окно «Изменение связей», в котором указываем тип обеспечения целостности. Завершается этот этап нажатием кнопки «Создать».

Формы -- одно из основных средств работы с базами данных в Access, используются для ввода новых записей, просмотра и редактирования уже имеющихся данных, задания параметров запросов и вывода ответов на них и др. Формы представляют собой окна с размещенными в них элементами управления. Существует возможность динамического создания форм при исполнении программы, однако естественным режимом их создания является режим визуального конструирования. Выбор команды «Форма» в меню «Вставка» выводит на экран окно «Новая форма», позволяющее задать таблицу или запрос дам которых создается новая форма, и указать режим ее создания. Создание формы можно автоматизировать, используя «Мастер форм».

Для создания формы с помощью Мастера форм предполагается следующая последовательность действий: меню Формы / Создать. На экране появится окно диалога «Новая форма», в котором необходимо выбрать метод построения формы и исходный объект для построения формы. В качестве такого объекта могут быть выбраны таблица или запрос.

На следующих шагах Мастер форм предлагает выбрать форму представления отчета (в столбец, ленточную, табличную или выровненную) и стиль оформления. Стили представляют собой набор различных фоновых рисунков с соответствующим подбором шрифтов и форм полей. На последнем шаге можно изменить предлагаемое название формы на свое собственное и завершить процесс создания формы, нажав кнопку «Готово».

В режиме конструктора можно создать специальные формы с листами данных, диаграммами и сводными таблицами в формате Excel. На форме можно расположить элементы управления в виде графических примитивов, надписей, рисунков и др. Элементы управления могут использоваться для ввода и отображения дат, а также для выполнения вычислений и вывода результата. Элементами управления являются кнопки команд, которые активизируют исполнение различных операций; объекты типа «подчиненные формы» (бланк таблицы, дочерней по отношению к форме); объекты, облегчающие восприятие данных, такие как календарь или счетчик, а также элементы пользователя.

Запросы. При разумном подходе к проектированию баз данных пользователи не получают прямой доступ к базовым таблицам, а делают это посредством запросов. Запрос может предоставлять пользователю выборку из полей одной таблицы или из полей разных таблиц. Создать запрос можно в режиме мастера или в режиме конструктора. Создадим запрос в режиме конструктора, для чего в окне базы данных следует щелкнуть на кнопках «Запрос» и «Конструктор». Прежде всего, откроется окно «Добавление таблицы», в котором и выберем таблицы, на основе которых строится запрос (допустим, ВУЗ и СТУДЕНТ). В результате откроется окно, называемое бланком запроса по образцу, где в верхней части указанные таблицы предстанут вместе со схемой данных. Двойным щелчком укажем на те поля, которые будут участвовать в запросе. Пусть это будут поля из таблицы СТУДЕНТ (ФАМИЛИЯ, ФАКУЛЬТЕТ) н из таблицы ВУЗ (НАЗВАНИЕ вуза), Указанные поля появятся в нижней части бланка запроса но образцу. Таким образом, нами был создан простейший запрос, который называется запрос на выборку на языке запросов но образцу (QBE Query By Example), При его активации кнопкой [!] будет построена таблица с указанием фамилии, факультета и вуза, в котором обучается студент. Закрытие запроса сопровождается присвоением ему имени. Заметим, что запрос на выборку создает не физическую таблицу на диске, а виртуальную в оперативной памяти, которая существует, пока мы пользуемся запросом.

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

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

Возможности языка QBE весьма широки, но все же ограничены. Если требуется нечто большее, то меню окна ЗАПРОС >ВИД > РЕЖИМ SQL позволяет построить запрос на языке SQL, более универсальном, но требующем специальных знаний.

Отчеты. Отчет похож на запрос, но служит для форматированного вывода данных на бумагу. Для создания отчетов рационально воспользоваться Мастером отчетов (база данных СОЗДАТЬ > НОВЫЙ ОТЧЕТ), который похож на Мастера форм. Выполняется отчет за ряд шагов, в процессе которых:

· выясняются таблицы и запросы, на основе которых строится отчет;

· поля, по которым производится сортировка, фильтрация;

· стиль оформления печатного документа.

Редактировать отчет, созданный Мастером, можно с помощью конструктора.

5. Литература

1. Информатика: учебник / Б. Д. Соболь [и др.] - Изд. 3-е, - Ростов-на-Дону: Феникс, 2007. - 446 [1] с.- (Высшее образование).

Размещено на Allbest.ru