Базы данных и информационные системы.

30. Основные понятия и определения.

Информационная система. Банки данных. База данных.

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

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

Основными функциями банков данных являются:

• хранение данных и их защита;

• изменение (обновление, добавление и удаление) хранимых данных;

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

• обработка данных и вывод результатов.

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

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

Прикладные программы(приложения) - в составе банков данных служат для обработки данных, вычислений и формирования выходных документов по заданной форме.

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

31. Процесс создания информационной системы.

проектирование БД -> создание файла проекта БД -> создание БД (формирование и связывание таблиц, ввод данных )-> создание меню приложения -> создание запросов -> создание экранных форм, отчетов -> генерация приложения как исполняемой программы

32. Архитектура информационной системы. Архитектура клиент-сервер

Эффективность функционирования информационной системы во многом зависит от ее архитектуры. В настоящее время перспективной является архитектура клиент-сервер.

В достаточно распространенном варианте архитектура клиент-сервер предполагает наличие компьютерной сети и распределенной базы данных, включающей корпоративную БД (БДК) и персональные БД (БДП).

БДК размещается на компьютере-сервере, БДП размещаются на компьютерах сотрудников подразделений, являющихся клиентами корпоративной БД

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

Клиентом — компьютер (программа), использующий этот ресурс.

33. Модели данных.Иерархическая. Сетевая.   Реляционная. Объектно-ориентированная.

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

• Модель данных в общем случае описывает набор базовых признаков, которыми должны обладать все конкретные СУБД и управляемые ими БД, основанные на этой модели.

К числу важнейших относятся следующие модели данных:

• иерархическая;

• сетевая;

• реляционная;

• объектно-ориентированная.

В иерархической модели данные представляются в виде древовидной (иерархической) структуры

Она удобна для работы с иерархически упорядоченной информацией и громоздка для информации со сложными логическими связями

Сетевая модель означает представление данных в виде произвольного графа.

Достоинством сетевой и иерархической моделей данных является возможность их эффективной реализации по показателям затрат памяти и оперативности.

Недостатком сетевой модели данных является высокая сложность и жесткость схемы БД, построенной на ее основе

Реляционная модель данных (РМД) название получила от английского термина relation — отношение.

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

• Реляционная модель данных используется в основном в БД среднего размера.

• При увеличении числа таблиц в базе данных заметно падает скорость работы с ней.

• Определенные проблемы использования РМД возникают при создании систем со сложными структурами данных, например, систем автоматизации проектирования

Объектно-ориентированные БД объединяют в себе две модели данных, реляционную и сетевую, и используются для создания крупных БД со сложными структурами данных

34. Системы управления базами данных.

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

Управляющим компонентом многих СУБД является ядро, выполняющее следующие функции:

• управление данными во внешней памяти;

• управление буферами оперативной памяти;

• управление транзакциями.

Транзакция — это последовательность операций над БД, рассматриваемая СУБД как единое целое.

Язык современной СУБД включает подмножества команд, относившиеся ранее к следующим специализированным языкам:

Для обработки команд пользователя или операторов программ в СУБД используются интерпретаторы команд и компиляторы.

35. Реляционная модель данных.

Элементы реляционной модели. Ограничения и операции над отношениями

• Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени.

• При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними.

Элемент реляционной модели	Форма представления
Отношение	Таблица
Схема отношения	Строка заголовков таблицы
Кортеж	Строка таблицы
Сущность	Описание свойств объекта
Атрибут	Заголовок столбца таблицы
Первичный ключ	Один или несколько атрибутов
Тип данных	Тип значений элементов таблицы

Важнейшим является понятие отношения, которое представляет собой двумерную таблицу, содержащую данные.

Множество всех значений каждого атрибута отношения образует домен.

Отношение СОТРУДНИК включает 4 домена:

1. Домен содержит фамилии всех сотрудников,

2. Домен содержит номера всех отделов фирмы,

3. Домен содержит название всех должностей,

4. Домен содержит даты рождения всех сотрудников.

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

36. Проблемы проектирования реляционных БД

Избыточное дублирование данных и аномалии. Формирование исходного отношения.

При проектирование реляционной БД должны быть решены следующие проблемы:

1) определиться со схемой БД: из каких отношений должны состоять БД, какие атрибуты должны быть у этих отношений, каковы связи между отношениями.

2) Обеспечить эффективность выполнения запросов к базе данных (физическое проектирование БД).

После проведения этапа даталогического проектирования должны быть получены следующие результирующие документы:

   Построение корректной схемы данных ориентируясь на реляционную модель данных.

   Описание схемы БД в терминах выбранной СУБД.

   Описание внешних моделей в терминах выбранной СУБД.

   Описание декларативных правил поддержки целостности БД.

   Разработка процедур поддержки семантической целостности БД.

Итак, задача проектирования реляционной БД состоит в выборе схемы базы из множества альтернативных вариантов.

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

Проектирование схемы БД можно выполнить двумя методами:

   Метод декомпозиции (разбиения) – исходное множество отношений, входящих в схему БД заменяется другим множеством отношений, являющихся проекциями исходных отношений! При этом число отношений возрастает.

   Метод синтеза – компоновка схемы БД из заданных исходных элементарных зависимостей между объектами предметной области.

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

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

В теории реляционных БД обычно выделяют следующие нормальные формы:

первая нормальная форма (1NF);

   вторая нормальная форма (2NF);

   третья нормальная форма (3NF);

   нормальная форма Байса-Кодда (BCNF);

   четвертая нормальная форма (4NF);

   пятая нормальная форма или форма проекции - соединения (5NF или PYNF).

Основные свойства нормальных форм:

   каждая следующая нормальная форма в некотором смысле лучше предыдущей;

   при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

37. Проектирование БД методом нормальных форм.

Зависимости между атрибутами: функциональная, транзитивная, многозначная. Нормальные формы: первая нормальная форма, вторая нормальная форма, третья нормальная форма, усиленная 3НФ (нормальная форма Бойса-Кодда БКНФ).

нормальные формы отношений.

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

   Аномалии вставки (INSERT) – хранение в одном отношении разнородной информации.

   Аномалии обновления (UPDATE) –избыточность данных отношения из-за хранения разнородной.

   Аномалии удаления (DELETE) – хранение разнородной информации в одном отношении.

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

Нормализация – разбиение таблицы на несколько, которые обладают лучшими свойствами при обновлении, вставке и удалении данных. Т.е. нормализация представляет собой процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ, однако, на практике достаточно привести таблицы к НФБК.

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

Если заменить на время нормализации коды первичных (внешних) ключей, то следует рассмотреть 2 случая:

1. Таблица имеет составной первичный ключ, например и поле , которое функционально зависит от части этого ключа, например, от (от полного ключа не зависит). Рекомендуется сформировать другую таблицу, содержащую и ( – первичный ключ), и удалить из первоначальной таблицы:

2. Таблица имеет первичный (возможный) ключ , поле , которое не является возможным ключом, но функционально зависит от , а также – другое неключевое поле , функционально зависящее от : . Рекомендуется сформировать таблицу содержащую и ( - первичный ключ), и – удалить из первоначальной таблицы:

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

Опр.1. Отношение находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из его строк не содержит в любом своем поле одного значения и ни одного из ключевых полей отношения не пусто.

По опр.1, любое отношение будет находиться в 1НФ, т.е. отношение, удовлетворяющее свойствам отношений: в отношении нет одинаковых кортежей; кортежи не упорядочены; атрибуты не упорядочены и различаются по наименованию; все значения атрибутов атомарны.

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

Если потенциальный ключ является простым, то отношение автоматически находится в 2НФ.

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

Атрибуты отношения называются взаимно-независимыми, если ни один из них не является функционально зависимым от другого.

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

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

При приведении отношений при помощи алгоритма нормализации к отношениям в 3НФ предполагается, что все отношения содержат один потенциальный ключ. Это не всегда верно. Бывают случаи, когда отношение может содержать несколько ключей.

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

Если отношение находится в НФБК, то оно автоматически находится в 3НФ, что следует из определения 4. Чтобы устранить зависимость от детерминантов, не являющихся потенциальными ключами, следует провести декомпозицию, вынося эти детерминанты и зависимые от них части в отдельное отношение.

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

38. Обеспечение целостности БД.

Ограничения диапазонов значений атрибутов отношений. Структурные ограничения на кортежи отношений.

39. Языки запросов QBE и SQL.

Для подготовки запросов с помощью различных СУБД, как правило, используются два основных языка описания запросов:

• QBE (Query By Example)

— язык запросов по образцу;

• SQL (Structured Query Language)

— структурированный язык запросов

Главное отличие между QBE и SQL заключается в способе формирования запросов:

• язык QBE предполагает ручное или визуальное формирование запроса,

• использование SQL означает программирование запроса. данных

Язык QBE позволяет задавать сложные запросы к БД путем заполнения предлагаемой СУБД запросной формы. Такой способ задания запросов обеспечивает высокую наглядность и не требует указания алгоритма выполнения операции — достаточно описать образец ожидаемого результата

С помощью языка QBE можно задавать однотабличные и многотабличные (выбирающие или обрабатывающие данные из нескольких связанных таблиц) запросы. В каждой из современных реляционных СУБД имеется свой вариант языка QBE.

При задании запросов с помощью языка QBE допустимы следующие операции:

• выборка данных;

• вычисление данных;

• модификация данных;

• вставка записей;

удаление записей.

Структурированный язык запросов SQL основан на реляционном исчислении с переменными кортежами

Язык имеет несколько стандартов, наиболее распространенными из которых являются SQL-89 и SQL-92.

SQL предназначен для выполнения операций:

1. над таблицами

создание,

удаление,

изменение структуры

1. над данными таблиц

выборка,

изменение,

добавление