Базы данных теория для практики

хранения, обработки и передачи информации.

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

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

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

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

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

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

СЕТЕВАЯ МОДЕЛЬ

В сетевой модели принята свободная связь
элементов между собой.

данных состоят из совокупности узлов и связей между ними. Каждый узел (элемент данных) в обеих моделях является записью.

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

обработки по субъекту пользования;
- высокая скорость обработки данных за счёт тесной связи с программами.
Недостатки файлового подхода:
- избыточность: данные в различных блоках дублируются;
- изменения в организации данных требуют коррекции программ обработки.

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

Концепция БД

База данных (БД) – именованная совокупность данных, отображающих состояние объектов и их отношения в рассматриваемой предметной
области.

общих задач;
модельность: данные представляют объекты реального мира;
взаимосвязанность;
данные и их описания хранятся совместно в БД и
не зависят от логики программ пользователей.
Блок данных, отвечающий требованиям 1)-4), можно рассматривать в качестве базы данных.

баз
данных, хранения и поиска в них необходимой информации.

СУБД

Основные функции СУБД:

поддержка выбранной пользователем модели данных;
2) использование языковых средств описания и манипуляции данными SQL (Structured Query Language);
3) поддержка операций создания и обработки данных (обновление, удаление, вставка, выбор по запросу и т.д.);
4) защита и целостность данных при коллективном пользовании.

Некоторые СУБД
Access, FoxPro, Paradox, dBase, FoxBase, Oracle, Postgres, Typhoon, LINCKS, Exodus, InterBase, PostgreSQL, Firebird, MySQL, Microsoft SQL, IBM DB2, Sav Zigzag, SQLite, Apache CouchDB, Cache, XSForms, eSQL …

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

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

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

Уровни проектирования:

предполагается хранить в создаваемой БД, является инфологическое моделирование (или модель «сущность-связь»).

Представление данных с помощью модели «сущность-связь»

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

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

требуемый экземпляр сущности.
Например, ключом сущности АВТОМОБИЛЬ является НОМЕРНОЙ ЗНАК.
Связь – это ассоциация, установленная между несколькими сущностями.
Например,
поскольку каждый сотрудник работает в каком-либо отделе, между сущностями СОТРУДНИК и ОТДЕЛ существует связь, которую назовем «работает в»;
могут существовать и связи между сущностями одного типа, например связь «родитель – потомок» между двумя сущностями ЧЕЛОВЕК;
Связь также может иметь атрибуты.
Например, для связи «работает в» можно задать атрибут СТАЖ_РАБОТЫ_В_ОТДЕЛЕ

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

имя
сущности

имя атрибута

имя
атрибута

имя связи

сущности А соответствует 1 или 0 представителей сущности В.

Характеристика связей

Между двумя сущностям, например, А и В возможны следующие виды связей.

Мужчина женат на одной женщине (традиционный брак).

или

ПРИМЕР изображения связи на ER-диаграмме:

или несколько представителей сущности В.

ПРИМЕР:

∞

или

Квартира может пустовать, в ней может жить один или несколько жильцов.

Между двумя сущностями возможны связи в обоих направлениях, поэтому существует связь МНОГИЕ-К-ОДНОМУ (М:1)

или несколько представителей сущности В, а одному представителю сущности В соответствуют 0, 1 или несколько представителей сущности А.

или

ПРИМЕР:

Покупатель может приобретать товар у нескольких продавцов, продавец может продавать товар нескольким покупателям

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

тернарные связи

Врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами.

связи более высоких порядков (смысл которых иногда очень сложен)

модели данных, например, реляционной модели данных.

Для построения логической модели требуется выполнить следующие действия:
1. Создать по одной таблице для каждой сущности и каждой связи.
2. Для каждой таблицы задать первичный и внешний ключи

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

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

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

1 этап Разработка концептуальной модели БД

Первый этап проектирования заключается в описании объектов базы данных – сущностей, определении их характеристик (атрибутов) и в установлении связей между сущностями.

будут обладать избыточностью:
- Студент,
Преподаватель,
Дисциплина.

каждой сущности и связи, имеющей атрибуты.
2. Для каждой сущности задать первичный и внешний ключи.

с помощью конкретной СУБД, например Access.

Создание таблиц с помощью Конструктора

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

Домен – множество допустимых
значений для заданного атрибута .
Не все они обязательно присутствуют
в данной таблице, а являются
возможными в принципе.
Например, домен “Имена” – определен
на базовом типе строк (символов), но
в число его значений могут входить
только те строки, которые
представляют имена.
Различные атрибуты могут быть определены на одном домене, например, дата рождения и дата приема на работу.

атрибутов в данном отношении, который однозначно определяет ( идентифицирует ) каждую запись в таблице.
То есть, значения ключевого атрибута для всех экземпляров данной таблицы различны. Ключ отношения для удобства размещают в первом столбце.
Примеры ключа: № зачетной книжки, ИНН налогоплательщика.
Помимо простого ключа (№ лицевого счета в банке) может встречаться
составной ключ (состоять из нескольких атрибутов, например, ПАСПОРТНЫЕ ДАННЫЕ: СЕРИЯ + № ПАСПОРТА )
Схема отношения представляется:
Перечнем имен отношения и атрибутов в виде R(A1, A2, …, Ak), где R – имя отношения; A1,…,Ak – имена атрибутов.
Описанием доменов для каждого атрибута
Условиями ограничения целостности, задаваемых на доменах (например, дата рождения не должна определять возраст более 200 лет).
Степень отношения – число его атрибутов (равна 4 в примере).
Кардинальное число – количество записей в таблице.

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

отношением может быть
ИЗУЧАЕТ(СТУДЕНТ, ПРЕДМЕТ), то есть оно
содержит ключи обоих объектных отношений.

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

Зачем нужна нормализация

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

обозначается 1НФ).
2. 2НФ
3. 3НФ
4. Нормальная форма Бойса-Кодда (НФБК).
5. 4НФ.
6. 5НФ.
На практике, как правило, ограничиваются третьей нормальной формой, ее оказывается вполне достаточно для создания надежной схемы БД.

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

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

Приведение отношения к 1НФ

Пример.

СТУДЕНТ

Очевидно, что в данном случае атрибут "Спорт" является сложным.

в отношении СТУДЕНТ все атрибуты простые, следовательно это отношение находится в 1НФ.

СТУДЕНТ

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

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

«Личный номер» и «Название предмета» из предыдущей лекции

ПРЕПОДАВАТЕЛЬ - ПРЕДМЕТ

Оно находится в 1НФ, поскольку не содержит составных атрибутов.

Отметим, что:

В этом отношении можно отметить частичную зависимость атрибутов «Фамилия», «Должность», «Оклад», «Кафедра», «Телефон» от части «Личный номер» составного ключа.

о преподавателе, поскольку преподаватель может читать несколько предметов.

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

3. Возникает проблема с преподавателями, которые в данное время не ведут предметы, а именно, преподавателя без предмета невозможно включить в отношение и наоборот, если преподаватель увольняется и удаляется из отношения, то будет удален и предмет, хотя предмет должен продолжать читаться.

разбить его на два отношения:

В итоге получим два отношения – ПРЕДМЕТ и ПРЕПОДАВАТЕЛЬ, находящиеся в 2НФ.

ПРЕДМЕТ

ПРЕПОДАВАТЕЛЬ

оно находится в 2НФ и в нем отсутствуют транзитивные зависимости неключевых атрибутов от ключа.

В полученном отношении ПРЕПОДАВАТЕЛЬ имеются транзитивные функциональные зависимости, например:
Личный номер→Кафедра→Телефон
Личный номер→Должность→Оклад

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

2. Нельзя включить данные о новой кафедре (название и номер телефона), если на данный момент еще отсутствуют преподаватели.

Для решения этих проблем необходимо разбить отношение ПРЕПОДАВАТЕЛЬ на три следующих отношения:

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