10. Реляционная модель. Терминология.

Реляционная модель значительно отличается от иерархической и сетевой. Основу реляционной модели составляет двумерная таблица.  Преимущества реляционной модели данных:  1. Структурная независимость (простота внесения изменений в структуру). 2. Гибкость. 3. Легкость поиска. 4. Возможность поиска в любом направлении. 5. Поддержка языка SQL.  Недостатки: 1. Неделимость данных на пересечении строки и столбца.  2. Ограниченность типов данных.  Требования к таблицам:  1. Данные должны быть структурно неделимы (атомарными).  2. Данные в одном столбце должны быть одного и того же типа данных. 3. Каждая строка должна быть уникальна (не допустимо дублирование).  4. Столбцы могут размещаться в произвольном порядке.  5. Строки могут размещаться в произвольном порядке.  6. Столбцы должны иметь уникальные имена.

Отношение - связь между некоторыми строками Связь - это запись таблицы. При заполнении строки надо придерживаться реляционной целостности. Столбец - атрибут сущности, где сущность это таблица. Ячейка - значения атрибута определенной записи 11. Реляционное исчисление.

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

Операции над реляционными таблицами: выборка, проекция, соединение, объединение, пересечение, разность, произведение. 12. Реляционные ключи.

Кортеж - строка, отношение. Ключ – столбец или набор столбцов которые однозначно определяют модель. Суперключ - ключ, атрибут или набор атрибутов, которые однозначно идентифицируют кортеж отношения. Потенциальный ключ - суперключ, который не содержит подмножеств атрибутов, которое само по себе является суперключём. Разновидности потенциальных ключей: 1. Первичный ключ (Primary Key, PK) - однозначно определяет кортеж. Бывает простой и составной. Может быть только один в таблице. Не может содержать пустых значений. 2 Уникальный. Однозначно определяет запись (в пределах одного значения или набора значений). Может быть несколько в таблице. Может содержать пустые значения. 3 Составной – уникальность комбинации (первичный + уникальный)  Вторичный ключ – атрибут или несколько атрибутов использующийся для поиска данных. Внешний ключ (Foreign Key) - атрибут или множество атрибутов внутри отношения, которое соответствует потенциальному ключу некоторого (возможно, того же самого) отношения.  13. Реляционная целостность.

Реляционная целостность - достоверность, непротиворечивость, корректность данных. Для обеспечения реляционной целостности требуется задание ограничений целостности, которые представляют собой правила, которым должны соответствовать данные.  3 вида целостности:  1. Целостность сущности. Требование: уникальность строк. Ограничение: наличие первичного ключа (PK).  2. Ссылочная целостность. Обеспечивает правильную связь таблиц. Ограничение: наличие внешнего ключа (FK).  3. Корпоративная целостность. Представляет собой дополнительные правила, которые действуют в пределах организации.  Ограничения (CHECK) задаются при описании столбцов. 14. Жизненный цикл базы данных.

Информационная система включает: БД, СУБД, прикладное программное обеспечение, аппаратные средства, персонал.

(1)Планирование разработки БД (2) Определения требований к системы (3)Сбор и анализ требований пользователя (4) Проектирование БД (4.1) Концептуальное проектирование (4.2) Логическое проектирование (4.3) Физическое проектирование (4.a) Выбор целевой СУБД (4.б) Создание прототипа (4.в) Разработка приложений (5) Реализация  (6)Конвертирование и загрузка данных  (7)Тестирование (8) Эксплуатация и сопровождение Планирование осуществляется для достижения максимальной производительности системы с минимальными затратами.  Определение требований к системе осуществляется определением диапазона функций и определением границ базы данных.  На этапе сбора и анализа требований пользователя собираются и анализируются требования каждой группы пользователей для всех возможных областей применения системы.  15. Моделирование данных.

Фактически, моделирование данных - первый шаг на пути проектирования базы данных, это переход от объектов реального мира к компьютерной модели базы данных.  Моделирование данных - это просто средство формального сбора данных, относящихся к бизнес-процессу данной организации. Моделирование является одним из главных на сегодняшний день приемов анализа, основанием, на котором строятся реляционные базы данных.  Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.  Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных.

Критерии оценивания качества модели данных: 1. Структурная достоверность (представление данных должно соответствовать способу определения и организации информации на данном предприятии) 2. Простота (лёгкость понимания модели, как профессионалам, так и обычным пользователям) 3. Выразительность (способность представлять отличия между типами данных, связями и ограничениями) 4. Отсутствие избыточности (исключение лишней информации) 5. Способность к совместному использованию (Отсутствие принадлежности к какому-либо приложению, использование модели многими приложениями) 6. Расширяемость (возможность дополнять при необходимости схему данных с минимальным влиянием на существующих пользователей) 7. Целостность (согласованность со способом использования и управления информацией внутри предприятия) 8. Представление модели в виде диаграмм 16. Этапы проектирования баз данных.

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

-Каждое поле должно быть связано с темой таблицы - Не рекомендуется включать в таблицу данные, являющиеся результатом выражения - В таблице должна присутствовать вся необходимая информация - Информацию следует разбивать на наименьшие логические единицы 4. Задание индивидуального значения каждому полю. С тем чтобы Microsoft Access мог связать данные из разных таблиц. Такое поле или набор полей называют основным ключом.  5. Определение связей между таблицами. Желательно изучать связи между таблицами в уже существующей базе данных.

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

8. Использование средств анализа в СУБД.

17. Концептуальное проектирование баз данных.

Этапы концептуального моделирования:  - Определение типов сущности.  - Определение типов связей.  - Определение атрибутов (свойств).  - Определение доменов атрибутов.  - Создание диаграммы "сущность-связь" (ЕR-модель).  - Обсуждение полученной модели с пользователем.

- Превращаем сущности в реляционную модель

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

Этап логического моделирования:  - Концептуальная модель преобразовывается в логическую.  - Логическая модель проверяется с помощью правил нормализации.  - Получение уточненной диаграммы "сущность-связь" с учетом элементов, полученных после нормализации.  - Задание условий проверки целостности данных (правильность и непротиворечивость данных).  - Обсуждение полученной ER-модели с пользователем. 19. Физическое проектирование баз данных.

Этапы физического проектирования:  1. Перенос логической модели данных в среду целевой СУБД.  1.1 Спроектировать основные таблицы  1.2 Реализовать бизнес-правила предприятия  2. Проектирование физического представления данных.  2.1. Выбор файловой структуры.  2.2. Определение индексов. 2.3. Анализ необходимости введения контролируемой избыточности. 2.4. Определение требований к дисковой памяти. 3. Разработка механизмов защиты. 3.1. Регистрация пользователей. 3.2. Установка прав доступа пользователей.  3.3. Создание пользовательских представлений.  4. Организация мониторинга и настройка функционирования системы 20. Модель "Сущность-связь" (ER).

Модель "сущность-связь" (ER-модель) дает графическое представление логических объектов (сущностей) и их отношений в структуре базы данных. Именно такое графическое представление данных сделало ER-диаграммы популярным средством на концептуальном уровне моделирования данных. Более того, ER-модель дополнила концепции реляционной модели, создав основы хорошо структурированной среды проектирования, гарантирующей надлежащую разработку реляционных баз данных. Основу ER-модели составляют следующие компоненты: сущность (логический объект), как "персону, местоположение или предмет, сведения о которых подлежат сбору и хранению".  В ER-модели сущность представлена в виде прямоугольника.  Название сущности (имя существительное) записывается в центре прямоугольника, как правило, заглавными буквами и предпочтительнее в единственном числе.  Каждая строка реляционной таблицы соответствует экземпляру сущности (entity instance или entity occurrence) в терминах ER-модели.  Сущность описывается набором атрибутов. Каждый атрибут описывает отдельное свойство сущности.  Связь описывает соединение между данными. Большинство связей описывает соединение между двумя сущностями.  Связь изображается на ER-диаграмме ромбом, соединенным с соответствующей сущностью. Название связи (в глагольной форме) записывается внутри ромба. 21. Концепция ER-модели.

ER-диаграммы используются для разработки данных и представляют собой стандартный способ определения данных и отношений между ними. Таким образом, осуществляется детализация хранилищ данных. ER-диаграмма содержит информацию о сущностях системы и способах их взаимодействия, включает идентификацию объектов (сущностей), важных для предметной области, свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).  Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.  Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.  Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности. 22. Нормализация данных. Цель нормализации, избыточность данных и аномалии обновления.

Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации. Общее назначение процесса нормализации заключается в следующем:  - исключение некоторых типов избыточности;  - устранение некоторых аномалий обновления;  - разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;  - упрощение процедуры применения необходимых ограничений целостности.  Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов). 23. Денормализация.

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

Функциональная зависимость - это когда один столбец или множество столбцов функционально зависят от одного или множества столбцов. Если данное множество для Х определяет единственное множество значений для Y ( Х -> Y).  Множество значений первичного ключа однозначно определяет значение первичного ключа.

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