Уроки 67 — 68самостоятельная работа. контрольная работа

Содержание

Существование ключей в реляционной базе данных

Первичный и вторичный ключи определяют потенциальные отношения базы данных. Реляционные связи модели данных могут иметь только один потенциальный ключ, это и будет primary key. Что же он собой представляет? Первичный ключ – это столбец сущности или набор атрибутов, благодаря которому можно получить доступ к данным конкретной строки. Он должен быть уникальным, единственным, а его поля не могут содержать пустых значений. Если первичный ключ состоит всего из одного атрибута, тогда он называется простым, в ином случае будет составляющим.


Кроме первичного ключа, существует и внешний (foreign key). Многие не понимают, какая между ними разница. Разберем их более детально на примере. Итак, существует 2 таблицы: «Деканат» и «Студенты». Сущность «Деканат» содержит поля: «ID студента», «ФИО» и «Группа». Таблица «Студенты» имеет такие значения атрибутов, как «ФИО», «Группа» и «Средний бал». Так как ID студента не может быть одинаковым для нескольких студентов, это поле и будет первичным ключом. «ФИО» и «Группа» из таблицы «Студенты» могут быть одинаковыми для нескольких человек, они ссылаются на ID номер студента из сущности «Деканат», поэтому могут быть использованы в качестве внешнего ключа.

Схема двумерной реляционной таблицы базы данных

Схема реляционной БД
Название атрибута 1 Название атрибута 2 Название атрибута 3 Название атрибута 4 Название атрибута 5
Элемент_1_1 Элемент_1_2 Элемент_1_3 Элемент_1_4 Элемент_1_5
Элемент_2_1 Элемент_2_2 Элемент_2_3 Элемент_2_4 Элемент_2_5
Элемент_3_1 Элемент_3_2 Элемент_3_3 Элемент_3_4 Элемент_3_5

Для детального понимания системы управления модели с помощью SQL лучше всего рассмотреть схему на примере. Нам уже известно, что представляет собой реляционная БД. Запись в каждой таблице – это один элемент данных. Чтобы предотвратить избыточность данных, необходимо провести операции нормализации.

Основные характеристики полей реляционных БД

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

Первая нормальная форма

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

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

Что происходит при добавлении третьего поставщика? Добавление поля не является ответом; для этого требуется изменение программ и таблиц, а также нестабильное динамическое количество поставщиков. Вместо этого разместите все сведения о поставщиках в отдельной таблице «поставщики», а затем свяжите запасы с поставщиками с ключом номера номенклатуры или поставщиками для запасов с ключом кода поставщика.

Особенности, структура и термины, связанные с реляционной моделью

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

  • реляционная табличка = сущность;
  • макет = атрибуты = наименование полей = заголовок столбцов сущности;
  • экземпляр сущности = кортеж = запись = строка таблички;
  • значение атрибута = ячейка сущности= поле.

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

  1. Сущность. Таблица реляционной базы данных может быть одна, а может быть целый набор из таблиц, которые характеризируют описанные объекты благодаря хранящимся в них данным. У них фиксированное количество полей и переменное число записей. Таблица реляционной модели баз данных составляется из строк, атрибутов и макета.
  2. Запись – переменное число строк, отображающих данные, что характеризируют описываемый объект. Нумерация записей производится системой автоматически.
  3. Атрибуты — данные, демонстрирующие собой описание столбцов сущности.
  4. Поле. Представляет собой столбец сущности. Их количество – фиксированная величина, устанавливаемая во время создания или изменения таблицы.

Теперь, зная составляющие элементы таблицы, можно переходить к свойствам реляционной модели database:

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

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

Основное понятие реляционной базы данных

Такая модель была разработана в 1970-х годах доктором науки Эдгаром Коддом. Она представляет собой логически структурированную таблицу с полями, описывающую данные, их отношения между собой, операции, произведенные над ними, а главное — правила, которые гарантируют их целостность. Почему модель называется реляционной? В ее основе лежат отношения (от лат. relatio) между данными. Существует множество определений этого типа базы данных. Реляционные таблицы с информацией гораздо проще систематизировать и придать обработке, нежели в сетевой или иерархической модели. Как же это сделать? Достаточно знать особенности, структуру модели и свойства реляционных таблиц.

Описание нормализации

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

Избыточные данные отнимают место на диске и создают проблемы с обслуживанием. Если необходимо изменить данные, которые находятся в нескольких местах, их необходимо изменить точно так же, как во всех местах. Изменение адресов клиентов значительно упрощается, если эти данные хранятся только в таблице Customers, а не в базе данных.

Что такое «несогласованная зависимость»? В отличие от того, что пользователь может искать в таблице Customers по адресу определенного клиента, может не иметь смысла искать зарплаты сотрудников, обращающихся к этому клиенту. Зарплата сотрудника связана с сотрудником или зависит от него, поэтому его следует переместить в таблицу Employees (сотрудники). Несогласованные зависимости могут усложнить доступ к данным, так как путь для поиска данных может отсутствовать или быть нарушен.

Существует несколько правил нормализации баз данных. Каждое правило называется «обычной формой». Если выполняется первое правило, база данных называется «Первая нормальная форма». Если выполняются первые три правила, база данных считается «третьей нормальной форме». Хотя возможны и другие уровни нормализации, Третья нормальная форма считается самым высоким уровнем, необходимым для большинства приложений.

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

В приведенных ниже описаниях приведены примеры.

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

1. Система управления базами данных — это: 2. База данных — это: 3. Организованную совокупность структурирован­ных данных в определенной предметной области называют: 4. Реляционная база данных может быть представ­лена в форме…5. Основным объектом для хранения информации в реляционных базах данных является: 6. Столбец однотипных данных в Ассеss называется:7. Строка, описывающая свойства элемента табли­цы, называется: 8. Записью в реляционных базах дан­ных называют:9. В поле файла реляционной базы данных (БД) могут быть записаны: 10. В записи файла реляционной базы данных (БД) может содержаться: 11. Структура файла реляционной базы данных (БД) полностью определяется: 12. Структура реляционной базы данных изменяет­ся при: 13. Имеется база данных. Сколько в ней полей?

Номер Фамилия Имя Отчество Год рожден ия Класс Школа
1 Сидоров Павел Ильич 1990 7 105
2 Смирнов Станислав Алексеевич 1991 9 49
3 Ефремов Василий Олегович 1990 11 2
4 Катан Андрей Никитич 1991 10 5

14. Имеется база данных (см. задание 13). Сколь­ко в ней числовых полей?15. Представлена база данных «Отделы». Какой тип имеет поле «Отдел» ?

Отдел Кол_сотр Нач_отд
310а 27 Шпак
101 в 26 Антонов
215 30 Чеботарев
101г 18 Ракитский
112 24 Кабанов

16. Сколько в базе данных записей?

Номер Компьютер Оперативная память Объем винчестера
1 Pentium II 32 4 Гб
2 Pentium III 128 40Гб
3 Pentium II 16 2 Гб
4 Pentium IV 256 80Гб

17. Имеется база данных (см. задание 16). Сколько в ней символьных полей?18. Условие поиска может задаваться с помощью: 19. Ключами поиска в СУБД называются: 20. Поле, значение которого не повто­ряется в различных записях, называется:21. Процесс упорядочения записей в таблице на­зывают: 22. Сортировкой называют: 23. В таблице представлен фрагмент базы данных «Расписание консультаций».

Номер Дата Время Класс Предмет Учитель Кабинет
1 2 июня 9 11 литература Ораина 25
2 2 июня 10 9 алгебра Кошкина 31
3 2 июня 10 11 алгебра Егоров 29
4 4 июня 9 9 физика Волков 20
5 4 июня 9 9 история Ларина 34
6 4 июня 11 11 физика Кривова 20

24. Имеется база данных:

Номер Фамилия Имя Отчество Год рожд. Класс Школа
1 Беляев Иван Петрович 1985 11 45
2 Катаев Сергей Иванович 1986 9 195
3 Иванов Петр Олегович 1988 7 135
4 Носов Антон Павлович 1986 10 4

25. Какие записи будут найдены в базе данных пос­ле проведения поиска в поле Оперативная память с ус­ловием >32 ?

Номер Компьютер Оперативная память Объем винчестера
1 Pentium II 32 4 Гб
2 Pentium III 128 40Гб
3 Pentium II 16 2 Гб
4 Pentium IV 256 80Гб

26. Какую строку будет занимать запись Pentium III (см. задание 25) после проведения сор­тировки по убыванию в поле Оперативная память ?27. Представлена база данных «Телефонный спра­вочник».

Фамилия И.О. Телефон
Иванов И. И. 234-56-98
Иванова А.П. 235-60-07
Кедров А.К. 435-88-78
Иванов И. К. 568-98-00
Иванников П. П. 384-15-15

28. После проведения сортировки исходной базы данных из задания 27 по полю Фамилия И.О. в порядке убывания запись, содержащая сведения о телефоне 384-15-15, переместится на: 29. По какому полю базы данных упорядочены записи?

Номер Фамилия Улица Дом Квартира Телефон
1 Иванов Советская 42 15 258-36-19
2 Петров Пушкина 15/2 366 366-56-98
3 Сидоров Гоголя 35 25 255-41-38
4 Кузьмин Гафури 69 38 564-89-71

30. Записи в базе данных упорядочены по полю (полям):

Марка Цвет Год выпуска Пробег, тыс. км
ВАЗ Красный 1989 50
ГАЗ ель Зеленый 1991 60
БМВ Желтый 1991 30
Тойота Синий 1995 20

31. Представлена база данных «Продажа автомо­билей».

Модель Цена Продано
ВМW 30 5
MERCEDES500 27 8
VAZ21099 10 12
Ford 22 2
UAZ 6 3

32. Дана реляционная база данных, содержащая сведения о воспитанниках спортивной школы.

Ф.И. Спорт Пол Возраст Рост Масса
1 Федоров И. лыжи муж. 17 174 69
2 Егоров В. биатлон муж. 15 160 62
3 Смирнова А. теннис жен. 16 165 52
4 Марков С. лыжи муж. 16 172 63
5 Виктова Н. биатлон жен. 14 168 54
задания 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
ответ 2 1 2 4 4 3 3 4 4 1 1 1 4 1 2 4
задания 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
ответ 2 3 3 4 3 4 2 1 4 2 1 4 2 1 3 2

Нормализация примера таблицы

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

Ненормализованная таблица: Учеников # Помощник Расширенное пространство Класс Class2 Class3 1022 Джонс 412 101-07 143-01 159-02 4123 Кузнецов 216 201-01 211-02 214-01

Первая нормальная форма: нет повторяющихся групп Таблицы должны иметь только два измерения. Так как один студент имеет несколько классов, эти классы должны быть перечислены в отдельной таблице. Поля Class1, Class2 и Class3 в вышеуказанных записях указывают на проблемы дизайна. Электронные таблицы часто используют третье измерение, но таблицы не должны. Другой способ просмотреть эту проблему — с отношением «один-ко-многим» не размещать одну сторону и сторону «многие» в одной и той же таблице

Вместо этого создайте другую таблицу в первой обычной форме, удалив повторяющуюся группу (class #), как показано ниже: Учеников # Помощник Расширенное пространство Классе # 1022 Джонс 412 101-07 1022 Джонс 412 143-01 1022 Джонс 412 159-02 4123 Кузнецов 216 201-01 4123 Кузнецов 216 211-02 4123 Кузнецов 216 214-01

Вторая нормальная форма: устранение избыточных данных Обратите внимание на несколько значений Class # для каждого значения Student # в приведенной выше таблице. Класс # не является функционально зависимым от Student # (первичный ключ), поэтому эта связь не находится в второй нормальной форме. В следующих двух таблицах показана Вторая нормальная форма: Приобретут Учеников # Помощник Расширенное пространство 1022 Джонс 412 4123 Кузнецов 216 Зарегистрировал Учеников # Классе # 1022 101-07 1022 143-01 1022 159-02 4123 201-01 4123 211-02 4123 214-01

Третья нормальная форма: исключите данные, не зависящие от ключа В последнем примере функционально заданное место (номер Office помощника) функционально зависит от атрибута Advisor

Решение состоит в том, чтобы переместить этот атрибут из таблицы Students в таблицу факультет, как показано ниже: Приобретут Учеников # Помощник 1022 Джонс 4123 Кузнецов Преподавателей Имя Комната Название Джонс 412 42 Кузнецов 216 42

Фундаментальные модели

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

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

Виды моделей данных

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

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

Различают три типа моделей данных, которые имеют множества допустимых информационных конструкций:

  • иерархическая;
  • сетевая;
  • реляционная.

Иерархическая модель данных

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

Основные понятия иерархической структуры


Это – узел, уровень и связь.

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

Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. К каждой записи базы данных существует только один (иерархический) путь от корневой записи. Например, как видно из рисунке, для записи С4 путь проходит через записи ВЗ к А.

Пример иерархической структуры:

Сетевая модель данных

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

На рисунке изображена сетевая структура базы данных в виде графа.

Пример сетевой структуры:

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

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

Понятие реляционный (англ. relation – отношение) связано с разработками известного американского специалиста в области систем баз данных Е.Кодда.

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

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

Отношение – это плоская таблица, содержащая N столбцов, среди которых нет одинаковых. N – это степень отношения, или арность отношения. Столбец отношения соответствует атрибуту сущности. Кортеж – строка отношения (соответствует записи в таблице).

Пример реляционной модели

№ личного дела Фамилия Имя Отчество Дата рождения Группа
16493 Сергеев Петр Михайлович 01.01.90 112
16593 Петрова Анна Владимировна 15.03.89 111
16693 Антохин Андрей Борисович 14.04.90 112

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

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

Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ. В примере ключевым полем таблицы является «№ личного дела».

Организация информации в реляционной базе данных

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

  • «один к одному». Связи данного типа предполагают наличие в двух связанных таблицах только одного одинакового атрибута;
  • «один ко многим». Это означает, что при данном типе связи один атрибут первой таблицы совпадает с несколькими атрибутами во второй;
  • «многие ко многим». В данном случае связи между двумя таблицами устанавливаются через несколько соответствующих друг другу атрибутов.

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

Чаще всего при работе с БД выполняются три основных правила нормализации, что относит базу данных к:

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

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

Узнать более подробно об организации информации в реляционных базах данных все желающие смогут в рамках профессиональной подготовки по курсу «Инструментальные средства бизнес-аналитики», которую проводит ВШБИ НИУ ВШЭ. Записаться на обучение по данному курсу можно на нашем сайте.

Процесс моделирования и составления основных элементов

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

Моделирование таблиц и проектирование реляционных баз данных производится посредством бесплатных инструментов, таких как Workbench, PhpMyAdmin, Case Studio, dbForge Studio. После детальной проектировки следует сохранить графически готовую реляционную модель и перевести ее в готовый SQL-код. На этом этапе можно начинать работу с сортировкой данных, их обработку и систематизацию.

Логическая структура реляционной базы данных

Связи между объектами модели данных реализуются одинаковыми реквизитами — ключами связи в соответствующих таблицах. При этом ключом связи типа 1 : M всегда является уникальный ключ главной таблицы. Ключом связи в подчиненной таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа (например, код фирмы в таблице СКЛАД). Ключ связи в подчиненной таблице называется внешним ключом.

Все связи в полученной информационно-логической модели предметной области «Поставка товара» характеризуются отношением типа 1 : M. Соответственно, связь между таблицами ПОКУПАТЕЛЬ и ДОГОВОР осуществляется по коду покупателя (КОД_ПОК), который является уникальным идентификатором главного объекта ПОКУПАТЕЛЬ и неключевым в объекте ДОГОВОР (см. табл. 2.6).


Связь между таблицами ТОВАР и ПОСТАВКА_ПЛАН осуществляется по уникальному ключу главного объекта ТОВАР — Коду товара, который в подчиненном объекте ПОСТАВКА_ПЛАН является частью ключа (см. табл. 2.6). Аналогично связь между таблицами ТОВАР и ОТГРУЗКА осуществляется по уникальному ключу главного объекта ТОВАР — Коду товара.

Связь между таблицами ДОГОВОР и НАКЛАДНАЯ осуществляется по уникальному ключу главного объекта ДОГОВОР — Номеру договора (НОМ_ДОГ), который в подчиненном объекте НАКЛАДНАЯ не входит в состав ключа (см. табл. 2.7).

Связь между таблицами ДОГОВОР и ПОСТАВКА_ПЛАН осуществляется по уникальному ключу главного объекта ДОГОВОР — Номеру договора (НОМ_ДОГ), который в подчиненном объекте ПОСТАВКА_ПЛАН является частью ключа (см. табл. 2.6). Аналогично связь между таблицами НАКЛАДНАЯ и ОТГРУЗКА осуществляется по уникальному составному ключу главного объекта НАКЛАДНАЯ — НОМ_НАКЛ + + КОД_СК, который в подчиненном объекте ОТГРУЗКА является частью ключа (см. табл. 2.7).

В Access может быть создана схема данных, наглядно отображающая логическую структуру базы данных. Определение одно-многозначных связей в этой схеме должно осуществляться в соответствии с построенной моделью данных. Топология проекта схемы данных практически совпадает с топологией информационно-логической модели. Для модели данных предметной области (см. рис. 2.18), построенной в рассмотренном примере, логическая структура базы данных в виде схемы данных Access приведена на рис. 2.19.

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

Базы данных: реляционные связи между таблицами

Существует 2 основных вида связей реляционных табличек:

«Один-многие». Возникает при соответствии одной ключевой записи таблицы №1 нескольким экземплярам второй сущности. Значок ключа на одном из концов проведенной линии говорит о том, что сущность находится на стороне «один», второй конец линии зачастую отмечают символом бесконечности.

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

Типы данных в базах

В Access можно определить следующие типы полей:

  • Текстовый – текстовая строка; максимальная длина задаётся параметром «размер», но не может быть больше 255
  • Поле МЕМО – текст длиной до 65535 символов
  • Числовой – в параметре «Размер поля» можно задать поле: байт, целое, дейсвительное и т.п.
  • Дата/время – поле, хранящее данные о времени.
  • Денежный – специальный формат для финансовых нужд, по сути являющийся числовым
  • Счётчик – автоинкрементное поле. При добавлении новой записи внутренний счётчик таблицы увеличивается на единицу и записывается в данное поле новой записи. Таким образом, значения этого поля гарантированно различны для разных записей. Тип предназначен для ключевого поля
  • Логический – да или нет, правда или ложь, включен или выключен
  • Объект OLE– в этом поле могут храниться документы, картинки, звуки и т.п. Поле является частным случаем BLOB– полей ( Binary Large Object ), встречающихся в различных базах данных
  • Гиперссылка – используется для хранения ссылок на ресурсы Интернета. Встречается не во всех форматах баз данных. К примеру, такого типа нет в dBaseи Paradox
  • Подстановка

Типы данных в таблицах Access 

  • Текстовый
  • Поле МЕМО
  • Числовой
  • Дата\время
  • Денежный
  • Счётчик
  • Логический
  • Объект OLE
  • Гиперссылка

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

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

Структура реляционных баз данных

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

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

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

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

Подробности

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

  • Каждый элемент таблицы является одним элементом данных
  • Каждый столбец обладает своим уникальным именем
  • Одинаковые строки в таблице отсутствуют
  • Все столбцы в таблице однородные, то есть все элементы в столбце имеют одинаковый тип
  • Порядок следования строк и столбцов может быть произвольным

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

Третья нормальная форма

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

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

ИСКЛЮЧЕНИЕ: следование третьей нормальной форме, хотя теоретически желательно, не всегда практично. Если у вас есть таблица Customers и вы хотите устранить все возможные зависимости между полями, необходимо создать отдельные таблицы для городов, почтовых индексов, торговых представителей, классов клиентов и других факторов, которые могут дублироваться в нескольких записях. Теоретически, нормализация стоит пурсинг. Тем не менее, многие небольшие таблицы могут понизить производительность или превышать количество файлов и емкости памяти.

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


С этим читают