Базы данных
Основные понятия БД - совокупность взаимосвязанных данных, совместно используемых несколькими приложениями и хранящимися с (минимальной) регулируемой избыточностью. Данные запоминаются таким образом, чтобы они, по мере возможности, не зависели от программ. Для обработки данных применяется общий управляющий метод доступа. (Дж. Мартин) БД - совместно используемый набор логически связанных данных (и их описание), предназначенный для удовлетворения информационных потребностей пользователей
Классификация баз данных
СУБД Система управления базами данных (СУБД) - это совокупность языковых и программных средств, которая осуществляет доступ к данным, позволяет их создавать, менять и удалять, обеспечивает безопасность данных и т. д. Основные функции СУБД: Непосредственное управление данными во внешней памяти Управление транзакциями Журнализация Поддержка языков БД
Уровни представления данных Современная технология баз данных основана на концепции многоуровневой архитектуры ( впервые была сформулирована в отчёте рабочей группы по базам данных Комитета по планированию стандартов Американского национального института стандартов (ANSI/X 3/SPARC), 1975).
Внешний уровень – это совокупность представлений данных, которые обрабатывают приложения и какими их видит пользователь на экране. Концептуальный уровень – это совокупность данных, используемых всеми приложениями. Т. е. это обобщенная модель предметной области, для которой созданы БД. Физический уровень – собственно расположенные на внешних носителях. данные,
На переходе "внешний – концептуальный" обеспечивается логическая независимость данных, на переходе "концептуальный – внутренний" – физическая независимость. Под логической независимостью подразумевается возможность вносить изменения в концептуальный уровень, не меняя представление БД для пользователей, или изменять представление данных для пользователей без изменения концептуальной схемы. Физическая независимость данных подразумевает возможность вносить изменения в схему хранения, не меняя концептуальную схему БД.
Модели данных Модель данных – это совокупность правил организации структур данных в базе данных, операций над ними, а также ограничений целостности, определяющих допустимые связи и значения данных, последовательность их изменения. Модели баз данных определяются тремя компонентами: - допустимой организацией данных; - ограничениями целостности; - множеством допустимых операций.
Модели данных Иерархическая Сетевая Реляционная Объектно-ориентированная модель
Иерархическая модель данных Информация в иерархической базе организована по принципу древовидной структуры, в виде отношений "предок-потомок". Каждая запись может иметь не более одной родительской записи и несколько подчиненных.
Иерархическая модель данных Атрибут (элемент данных) - наименьшая поименованная структурная единица данных Запись - именованная совокупность атрибутов. Экземпляр записи - конкретная запись с конкретным значением элементов Групповое отношение - иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) - подчиненными.
Иерархическая модель данных
Иерархическая модель данных Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой, по иерархическому пути. (Шифр_факультета+Номер_курса+Номер_группы+Номер_з ачётной_книжки).
Иерархическая модель данных
Операции над данными, определенные в иерархической модели Добавить в базу данных новую запись. Для корневой записи обязательно формирование значения ключа. Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям. Удалить некоторую запись и все подчиненные ей записи. Извлечь корневую запись по ключевому значению, допускается также последовательный просмотр корневых записей. следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева). Все операции изменения применяются только к одной "текущей" записи) (которая предварительно извлечена из базы данных)
Ограничение целостности обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).
Основные недостатки иерархической модели невозможность реализовать отношения "многие-ко-многим", а также ситуации, когда запись имеет несколько предков поддерживается только целостность связей между владельцами и членами группового отношения (никакой потомок не может существовать без предка) дублирование данных. Оно вызвано тем, что каждая сущность (атрибут) может относиться только к одной родительской сущности Например, если в БД хранятся данные о детях сотрудников, а на предприятии работает и отец, и мать ребёнка, то сведения об этом ребёнке нужно хранить дважды.
Сетевая модель данных Сетевая модель - это расширение иерархической структуры. Все то же самое, но существует связь "многие ко многим". Определяется в тех же терминах, что и иерархическая (атрибут, запись, групповое отношение).
Пример записи типов ОТДЕЛЫ и ОРГАНИЗАЦИИ-ЗАКАЗЧИКИ являются владельцами записей типа ПРОЕКТЫ и они связаны групповыми отношениями соответственно выполняют и заказывают. Записи типов ОТДЕЛЫ и ПРОЕКТЫ являются владельцами записей типа СОТРУДНИКИ и они связаны групповыми отношениями работают и выполняются. Записи типа СОТРУДНИКИ являются владельцами записей типа ДЕТИ.
Операции над данными в сетевой БД ДОБАВИТЬ - внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, где она объявлена подчиненной, либо не включать ни в какое групповое отношение. ВКЛЮЧИТЬ В ГРУППОВОЕ ОТНОШЕНИЕ - связать существующую подчиненную запись с записью-владельцем. ПЕРЕКЛЮЧИТЬ - связать существующую подчиненную запись с другой записью-владельцем в том же групповом отношении. ОБНОВИТЬ - изменить значение элементов предварительно извлеченной записи. ИЗВЛЕЧЬ - извлечь записи последовательно по значению ключа, а также используя групповые отношения - от владельца можно перейти к записям - членам, а от подчиненной записи к владельцу набора. УДАЛИТЬ - убрать из БД запись.
Ограничения целостности Обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).
Реляционная модель В реляционной модели все данные представлены для пользователя в виде таблиц, и все операции над базой данных сводятся к манипуляциям с таблицами. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка (запись)— конкретный объект.
Свойства таблиц В таблице не может быть двух одинаковых строк. В математике таблицы, обладающие таким свойством, называют отношениями - по-английски relation, отсюда и название - реляционные. Столбцы располагаются в определенном порядке, который создается при создании таблицы. В таблице может не быть ни одной строки, но обязательно должен быть хотя бы один столбец. У каждого столбца есть уникальное имя (в пределах таблицы), и все значения в одном столбце имеют один тип (число, текст, дата. . . ). На пересечении каждого столбца и строки может находиться только атомарное значение (одно значение, не состоящее из группы значений). Таблицы, удовлетворяющие этому условию, называют нормализованными.
Пример Создание базы данных для форума. У форума есть зарегистрированные пользователи, которые создают темы и оставляют сообщения в этих темах. Эта информация и должна храниться в базе данных.
Таблица противоречит свойству атомарности (одно значение в одной ячейке), а в столбцах Темы и Сообщения у нас предполагается неограниченное количество значений.
Таблица Пользователи удовлетворяет всем условиям. Таблицы Темы и Сообщения - нет. В таблице не может быть двух одинаковых строк, а где гарантия, что один пользователь не оставит два одинаковых сообщения. Каждое сообщение обязательно относится к какой-либо теме. При данной структуре – это не понятно.
Ключи Первичный ключ (primary key) - столбец, значения которого во всех строках различны. Первичные ключи могут быть логическими (естественными) и суррогатными (искусственными). Для таблицы Пользователи первичным ключом может стать столбец e-mail – логический ключ Порядковый номер записи в таблице или дополнительной поле – идентификатор(Id) – суррогатный ключ
Каждая запись в таблицах уникальна
Предположим, у нас добавился новый пользователь, и зовут его тоже Вася. Как мы узнаем, какой именно Вася оставил сообщения? Для этого поля автор в таблицах "Темы" и "Сообщения" мы сделаем также внешними ключами:
Схема базы данных
Проектирование БД 1. Системный анализ предметной области 2. Концептуальное проектирование - сбор, анализ и редактирование требований к данным. 3. Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБДориентированную структуру базы данных и спецификации прикладных программ. 4. Физическое проектирование - определение особенностей хранения данных, методов доступа и т. д.
Системный анализ предметной области Интеграция данных, предназначенных для решения прикладных задач разных пользователей. Учитываются требования к данным каждого пользователя, основанные на его представлении о данных и связях между ними. Требования обобщаются в единое представление, которое и является основой для построения БД
Концептуальная модель базы данных Обобщение представлений всех пользователей о данных называется концептуальной моделью БД. Концептуальная модель представляет информационное описание предметной области с учетом логических взаимосвязей, поэтому её еще называют инфологической (информационно-логической) моделью.
Модель «Сущность-связь» Сущность – любой различимый объект , информацию о котором необходимо хранить в базе данных. Экземпляр сущности – экземпляр конкретной сущности Атрибуты сущности – это свойства сущности, которые Связи – это взаимоотношения сущностей
Типы связей Связь один к одному (1: 1) – одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. Связь один ко многим (1: М) – один экземпляр сущности связан со многими экземплярами другой сущности. Связь многие ко многим (М: N) – несколько экземпляров одной сущности связаны с несколькими экземплярами другой сущности.
Диаграммы сущностей – связей (ER-диаграммы)
Пример (подсистема учета персонала) 1. Определяем сущности СОТРУДНИК КОНТРАКТ ДОЛЖНОСТЬ ОТДЕЛ ЗАКАЗЧИК
2. Определяем атрибуты сущностей
3. Определяем связи
Связь 1: N Означает, что сущности с одной ролью может соответствовать любое число сущностей с другой ролью (в каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе)
Связь M: 1 Эта связь аналогична отображению 1 : n (с одним заказчиком может быть заключено более одного контракта)
Связь M: N Каждая из сущностей может быть представлена любым количеством экземпляров (для выполнения каждого контракта создается рабочая группа, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько (в том числе и ни в одну) рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА имеет степень m : n)
Зависимые сущности Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (рабочая группа создается только после того, как будет подписан контракт с заказчиком, и прекращает свое существование по выполнению контракта. Таким образом, сущность РАБОЧАЯ_ГРУППА является зависимой от сущности КОНТРАКТ).
Логическое проектирование (преобразование модели в реляционную) Преобразование концептуальной модели в реляционную состоит в следующем: 1. 2. Построить набор предварительных таблиц и указать первичные ключи. Провести процесс нормализации.
Пример: Набор предварительных таблиц определены таблицы, поля, первичные ключи (РК) и связи (FK)
Нормализация - это пошаговый, обратимый процесс замены исходной схемы другой схемой, в которой таблицы имеют более простую и логичную структуру и устранена избыточности данных. Различают: 1 НФ - первая нормальная форма 2 НФ - вторая нормальная форма 3 НФ - третья нормальная форма НФБК - нормальная форма Бойса-Кодда 4 НФ - четвертая нормальная форма 5 НФ - пятая нормальная форма
Каждая нормальная форма налагает определенные ограничения на данные. Каждая нормальная форма более высокого уровня предполагает, что анализируемая таблица уже находится в нормальной форме на уровень ниже рассматриваемой. В ходе нормализации схема базы данных становится все более строгой, а ее таблицы все менее подвержены различного рода аномалиям. Для реляционных баз данных необходимо, чтобы ее таблицы находились в 1 НФ (рекомендуется довести структуру до 3 НФ)
Первая нормальная форма Таблица находится в первой нормальной форме, если все ее поля имеют простые (атомарные) значения.
Первая нормальная форма В таблице Поставщики есть поле Адрес. Если магазин работает только с поставщиками из одного города, то значения поля Адрес можно считать атомарными, а саму таблицу - приведенной к 1 НФ. Если поставщики находятся в разных городах, то посылая машину за товарами в определенный город, мы должны быть уверенны, что она заберет товары у всех поставщиков, находящихся в этом городе. Т. е. нам могут понадобиться сведения о поставщикам, находящихся в определенном городе. В этом случае, значения в поле Адрес уже не являются атомарными (т. к. мы используем часть адреса), и для приведения таблицы к 1 НФ нам надо выделить еще одно поле - Город Таким образом надо проанализировать все таблицы нашей базы данных
Вторая нормальная форма Эта форма применяется к таблицам с составными ключами. Таблица, у которой первичный ключ включает только одно поле, всегда находится во 2 НФ. Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, а каждое не ключевое поле функционально полно зависит от составного ключа. В нашей базе данных две таблицы имеют составной ключ - Журнал покупок и Журнал поставок. Значение поля Количество зависит, как от Поставки (Покупки), так и от Товара. Значит, наши таблицы находятся во 2 НФ.
Третья нормальная форма Таблица находится в третьей нормальной форме, если она находится во второй нормальной форме, и каждое не ключевое поле не транзитивно зависит от первичного ключа. Транзитивная зависимость наблюдается в том случае, если одно из двух не ключевых полей зависит от первичного ключа, а другое зависит от первого не ключевого поля. Пример: Рассмотрим таблицу Товар. В ней есть поле Цена, но цены, как известно, имеют свойство меняться. Если мы будем их менять прямо здесь, то будет пропадать вся информация о предыдущих ценах. Чтобы не терять эту информацию, надо добавить поле Дата (когда изменилась цена).
Даже не прибегая к 3 НФ видно, что такая таблица будет содержать избыточную информацию. Поля таблицы Товар: поля Наименование и Дата зависят от id товара, а поле Цена зависит также и от Даты. Т. е. таблица не находится в 3 НФ. Для устранения транзитивной зависимости необходимо провести "расщепление" объекта на два
Схема базы данных после нормализации
Дальше необходимо эту модель реализовать в конкретной СУБД. Для этого нам понадобится сама СУБД и знание языка SQL.
Физическое проектирование На этом этапе необходимо на конкретной СУБД, которую выбрали ранее, реализовать базу данных по той информации, которую собрали, обработали и подготовили (на предыдущих этапах проектирования базы данных). Описываются модули, их назначение, а также структура модулей. Физическое проектирование заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных Для реляционной БД на этом этапе определяются параметры распределения памяти для объектов БД, строятся индексы, определяется целесообразность использования хеширования и кластеризации
Основные функции реляционной СУБД Обеспечение многопользовательского режима доступа. База данных создаётся для решения многих задач многими пользователями. Это подразумевает возможность одновременного доступа многих пользователей к данным. Данные в БД являются разделяемым ресурсом, и СУБД должна обеспечивать разграничение доступа к ним. Обеспечение физической целостности данных. Проблема обеспечения физической целостности данных обусловлена возможностью разрушения данных в результате сбоев и отказов в работе вычислительной системы или в результате ошибок пользователей. Развитые РСУБД позволяют в большинстве случаев восстановить потерянные данные. Восстановление данных чаще всего основано на периодическом создании резервных копий БД и ведении журнала регистрации изменений (журнала транзакций).
Управление доступом. Для многопользовательских систем актуальна проблема защиты данных от несанкционированного доступа. Каждый пользователь этой системы в соответствии со своим уровнем (приоритетом) имеет доступ либо ко всей совокупности данных, либо только к её части. Управление доступом также подразумевает предоставление прав на проведение отдельных операций над отношениями или другими объектами БД.
Настройка СУБД обычно выполняется администратором БД, отвечающим за функционирование системы в целом. В частности, она может включать в себя следующие операции: подключение внешних приложений к БД; модификация параметров организации среды хранения данных с целью повышения эффективности системы; изменение структуры хранимых данных или их размещения в среде хранения (реорганизация БД) для повышения производительности системы или повторного использования освободившейся памяти; модификацию концептуальной схемы данных (реструктуризация БД) при изменении предметной области и/или потребностей пользователей.
Итоги Проектирование БД процесс, как правило, трудоемкий и небыстрый. Нужно очень хорошо изучить предметную область, чтобы учесть все нюансы, пожелания и требования пользователей. Собранную информацию изобразить в виде объектов, атрибутов и связей.
Исторически для системы управления базой данных сложились три языка: язык описания данных (ЯОД), называемый также языком описания схем, - для построения структуры ("шапки") таблиц БД; язык манипулирования данными (ЯМД) - для заполнения БД данными и операций обновления (запись, удаление, модификация); язык запросов - язык поиска наборов величин в файле в соответствии с заданной совокупностью критериев поиска и выдачи затребованных данных без изменения содержимого файлов и БД (язык преобразования критериев в систему команд).
