Руководство по разработке структуры и проектированию базы данных

MySQL

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

Поскольку MySQL является отраслевым стандартом, она совместима практически со всеми операционными системами и написана на языках C и C ++. Это решение является отличным вариантом для международных пользователей. Сервер СУБД может выводить клиентам сообщения об ошибках на нескольких языках.

Достоинства

  • Проверка на стороне сервера;
  • Может использоваться как локальная база данных;
  • Гибкая система привилегий и паролей;
  • Безопасное шифрование всего трафика паролей;
  • Библиотека, которая может быть встроена в автономные приложения;
  • Предоставляет сервер в качестве отдельной программы для сетевого окружения клиент/сервер.

Недостатки практической разработки и администрирования баз данных MySQL Приобретена компанией Oracle:

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

В этой статье

Чтобы создать отношение в базе данных Access, можно воспользоваться одним из указанных ниже методов.

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

Перетащите поле в таблицу из области Список полей.

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

Ключи в Access

Поля, которые формируют связь между таблицами в Access, называют ключами. Как правило, ключ состоит из одного поля, но может включать и несколько. Существуют 2 вида ключей.
1. Первичный. Он может быть в таблице только один. Такой ключ состоит из одного либо нескольких полей, однозначно определяющих каждую запись в таблице. Нередко в качестве первичного ключа применяют уникальный идентификатор, код либо порядковый номер. К примеру, в таблице «Клиенты» можно назначить уникальный код клиента каждому клиенту. Поле кода клиента в таком случае будет являться первичным ключом данной таблицы. Если же первичный ключ состоит из нескольких полей, он обычно включает уже существующие поля, которые формируют уникальные значения в сочетании друг с другом. Допустим, в таблице с информацией о людях в качестве первичного ключа мы можем использовать сочетание фамилии, даты рождения и имени.
2. Внешний ключ. В таблице также могут быть несколько внешних ключей (либо один). Этот ключ содержит значения, которые соответствуют значениям первичного ключа другой таблицы. К примеру, в таблице «Заказы» каждый заказ может включать код клиента, который соответствует конкретной записи в таблице «Клиенты». А поле «Код клиента» будет внешним ключом таблицы «Заказы».

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

Если мы хотим связать каждый заказ с клиентом, мы можем добавить в таблицу «Заказы» поле внешнего ключа, которое соответствует полю «Код» в нашей таблице «Заказчики», после чего создать связь между данными 2-мя ключами. В случае добавления записи в таблицу «Заказы» мы могли бы использовать значение кода клиента из нашей таблицы «Заказчики». Тогда во время просмотра каких-нибудь данных о клиенте, который сделал заказ, связь позволила бы определить, какие именно данные из нашей таблицы «Заказчики» соответствуют тем либо иным записям в нашей таблице «Заказы»:

  1. Первичный ключ, определяемый по знаку ключа рядом с именем поля.
  2. Внешний ключ, определяемый по отсутствию знака ключа.

Проектирование реляционной базы данных. Преобразование модели в реляционную

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

Из набора таблиц состоят наши объекты, а из полей таблиц — атрибуты объектов:

Итак, мы определились с таблицами, полями, РК и FK. Следует отметить, что в таблицах «Журнал покупок» и «Журнал поставок» РК составные, т. к. состоят из 2-х полей.

Что касается нормализации, то под ней понимают обратимый и пошаговый процесс, при котором исходная схема меняется другой схемой, в которой таблицы характеризуются более простой и логичной структурой. Это нужно по следующим причинам:
1. Устранение избыточности данных. Вспомним нашу таблицу:

Очевидно, что в поле «Темы» одни и те же названия встречаются регулярно. Для хранения таких данных нужны дополнительные ресурсы памяти. Кроме того, при дублировании данных можно допустить ошибку во время ввода значений атрибута, вследствие которой БД перейдёт в состояние несогласованности.
2. Устранение различных аномалий, связанных с обновлением, удалением, модификацией и пр. Пример аномалии модификации — чтобы поменять название темы, нам придётся смотреть все строки и менять название в каждой из них.

Нормализация бывает:
— 1-й нормальной формы (1НФ);
— 2НФ;
— 3НФ;
— НФБК (нормальной формы Бойса-Кодда);
— 4НФ;
— 5НФ.

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

Если говорить о реляционных базах данных, то минимум — это 1НФ. Однако в процессе проектирования специалисты по СУБД стремятся нормализовать базу хотя бы до уровня 3НФ, исключив тем самым избыточность данных и аномалии

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

Итак, в процессе проектирования мы преобразовали концептуальную модель в реляционную. Следующий этап — реализация её в конкретной СУБД. Для этого потребуется как сама СУБД, так и знание языка SQL. Например, прекрасно подойдёт СУБД MySQL или какая-нибудь другая СУБД.

Добавление индексов и представлений

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

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

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

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

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

Создание таблицы Customers

  1. В Обозреватель сервера разверните узел подключения к данным , а затем узел сампледатабасе. mdf .

    если не удается развернуть узел подключения к данным или отсутствует подключение сампледатабасе. mdf, нажмите кнопку Подключение к базе данных на панели инструментов обозреватель сервера. в диалоговом окне добавление соединения убедитесь, что в поле источник данных выбран Microsoft SQL Server файл базы данных , а затем найдите и выберите файл сампледатабасе. mdf. Завершите добавление подключения, нажав кнопку ОК.

  2. Щелкните правой кнопкой мыши таблицы и выберите команду Добавить новую таблицу.

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

  3. В сетке добавьте строку для каждой из следующих записей.

    Имя столбца Тип данных Разрешить значения null
    False (не установлен)
    False (не установлен)
    True (установлен)
    True (установлен)
  4. Щелкните строку правой кнопкой мыши и выберите пункт Задать первичный ключ.

  5. Щелкните строку по умолчанию () правой кнопкой мыши и выберите пункт Удалить.

  6. Назовите таблицу «Клиенты» путем обновления первой строки в области скриптов, как показано в следующем примере:

    Отобразятся примерно следующие сведения:

  7. В левом верхнем углу Конструктор таблиц выберите Обновить.

  8. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

    Таблица Customers создается в файле локальной базы данных.

Создание таблицы Orders

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

    Имя столбца Тип данных Разрешить значения null
    False (не установлен)
    False (не установлен)
    True (установлен)
    True (установлен)
  2. Задайте OrderID в качестве первичного ключа, а затем удалите строку по умолчанию.

  3. Назовите таблицу «Заказы» путем обновления первой строки в области скриптов, как показано в следующем примере:

  4. В левом верхнем углу Конструктор таблиц выберите Обновить.

  5. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

    Таблица Orders создается в файле локальной базы данных. Если развернуть узел таблицы в обозреватель сервера, отобразятся две таблицы:

Создание внешнего ключа

  1. В контекстной области в правой части сетки конструктор таблиц для таблицы Orders щелкните правой кнопкой мыши внешние ключи и выберите Добавить новый внешний ключ.

  2. В появившемся текстовом поле замените текст ToTable на Customers.

  3. в области T-SQL обновите последнюю строку, чтобы она соответствовала следующему примеру:

  4. В левом верхнем углу Конструктор таблиц выберите Обновить.

  5. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

    Создается внешний ключ.

Завершение первичного проекта

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

Может случиться так, что каждый продукт будет иметь несколько штрих-кодов, потому что если производитель вносит значительные из­менения в упаковку продукта, он также часто меняет и штрих-код. Например, все наверняка видели упаковки с надписью «+20% бес­платно», стоимость такой (например) бутылки лимонада не меняется, но зато благодаря этой рекламной акции лимонада вы получаете боль­ше. Обычно в таких случаях производители изменяют штрих-код, но сам продукт, по существу, не меняется. Возникает отношение: мно­жество штрих-кодов для одного продукта. Добавляем таблицу для хранения штрих-кодов (рис. 5):

Рис. 5. Добавление в базу данных таблицы BARCODE

Заметьте, что стрелка идет в направлении от таблицы BARCODE к табли­це ITEM, потому что именно штрих-кодов может быть несколько для од­ного товара

Обратите внимание на то, что barcode_ean является пер­вичным ключом, т. к

для каждого штрих-кода должна существовать уникальная строка и (хотя один продукт и может иметь несколько штрих-кодов) ни один штрих-код не может принадлежать более чем одному продукту.

Наконец, последнее добавление, которое следует внести в проект базы данных, — объем запасов каждого продукта.

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

Но может быть и так, что у нас множество товаров, при этом чаще все­го лишь какие-то из них присутствуют на складе, а объем инфор­мации, которую приходится хранить для товаров, находящихся на складе, весьма велик. Например, для склада необходимо хранить ин­формацию о размещении, номерах партий и сроках годности. Если в картотеке имеется 500 000 товаров, а на складе есть только 1000, то хранение данных по всем товарам будет просто расточительством. У этой проблемы есть стандартное решение — дополнительная таблица.

Следует создать новую таблицу, в которой хранилась бы «дополни­тельная информация» (например, сведения о хранении на складе), а затем создать только нужные строки — для продуктов, имеющихся в наличии на складе. Эти данные будут ссылаться на основную таблицу. На самом деле все гораздо проще, чем может показаться из этого объ­яснения. Окончательный проект первого варианта нашей базы дан­ных, с которым мы будем работать далее, представлен на рис. 2.19:

Рис. 2.19. Добавление в базу данных таблицы stock

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

ствующим товаром в таблице item используется . Стрелка ука­зывает на таблицу item, потому что это главная таблица, хотя в данном случае и нет отношения «многие-к-одному».

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

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

Сохранение, добавление, удаление

В Microsoft Access изменения сохраняются автоматически при следующих действиях:

  • Переход к следующей записи
  • Закрытие режима таблицы или формы

Добавление и удаление записей

Для добавления данных в новую запись:

  1. Перейдите на пустое поле новой записи
  2. Введите новую группу с количеством студентов и проходным баллом, нажимая TabилиEnter для перехода к следующему полю

Для удаления записей:

  1. Выделите записи для удаления, щелкнув курсором на серой кнопке слева от первой удаляемой записи и переместив указатель вдоль требуемых записей.
  2. Нажмите Del или выберите команду Правка|Удалить записи

Примечание:

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

БД из трех таблиц

Сначала необходимо спроектировать структуру базы данных. Например, БД «Учеба».

В ней будет  3 таблицы с полями (полужирным начертанием выделены ключевые поля):

1. «Список курсантов» — №, фамилия, имя, день рождения, пол, улица, дом, кв, группа.

2. «Группы» — номер группы, название группы, преподаватель.  

3. «Успеваемость» — код, фамилия, имя, любые 6 предметов.

Ключевые поля можно сделать тип счетчик или числовой.

Откройте новую базу данных Microsoft Access

Сохраните ее в своей папке с именем «Учеба».

Таблицы в ней создадим в режиме Конструктор. 

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

Создадим схему базы данных для данных таблиц во вкладке Работа с базами данных.

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

Таблицы «Группы» и «Список учеников» связать связью «один-ко-многим», а таблицы «Список учеников» и  «Успеваемость» — связью «один-к-одному». Таблицы «Группы» и «Успеваемость» напрямую не связаны. 

Задание.

Запрос выполняется на вкладке Создание. Выполнить запрос для выделения учащихся (их группу и преподавателей), у которых одновременно экзаменационный балл по химии меньше 75 и больше 50, а по информатике балл  меньше 80 и больше 60. Предоставь результат для проверки.

Вставка рисунка или объекта

Создание других таблиц для этой базы данных — аналогичное. 

Создайте еще 5 таблиц самостоятельно.

Вставка в запись рисунка или объекта

Рисунок или объект добавляется из имеющегося файла либо создается в приложении OLE (например, в MS Paint), а затем вставляется в текущую запись.

Рассмотрим размещение объекта OLE на примере поля Фотография начальника в таблице Преподаватели. Фотографии хранятся в формате графического редактора Paint в файлах с расширением .bmp. Если рисунка в вашем файле нет, то создайте его самостоятельно и сохраните.

  1. В окне базы данных установите курсор на таблице Преподаватели и нажмите кнопку Открыть
  2. Заполните строки (записи) открывшейся таблицы данными в соответствии с названиями столбцов (полей)
  3. Для размещения поля Фотография начальника выполните внедрение объекта OLE в файл базы данных. Установите курсор в соответствующее поле таблицы. Выполните команду меню Вставка|Объект
  4. В окне Вставка объекта выберите тип объекта Paintbrush Picture и установите флажок Создать из файла
  5. В этом окне можно ввести имя файла, содержащего фотографию.
  6. Для просмотра внедренного объекта установите курсор в соответствующее поле и дважды щелкните кнопкой мыши
  7. Чтобы вернуться из программы Paint, выполните команду Файл|Выход и возврат к таблице Преподаватели.
Размещение данных типа МЕМО в таблице

В таблице ПРЕДМЕТ предусмотрено поле ПРОГРАММА, которое будет содержать длинный текст – краткую программу курса. Для такого поля выберите тип данных ПолеМЕМО.

Отношения между таблицами в Access

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

Так как наши данные по различным темам хранятся в отдельных таблицах, их надо связать — это позволит комбинировать данные из различных таблиц. Для этого нам и нужны связи — логические отношения между 2-мя таблицами, основанные на их общих полях.

Создание связей между сущностями

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

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

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь «один-к одному» (часто обозначается 1:1). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

Если при проектировании и разработке баз данных у вас нет оснований разделять эти данные, связь 1:1 обычно указывает на то, что в лучше объединить эти таблицы в одну.

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

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

Связь «один-ко-многим»

Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи «один- ко-многим» (1:M) обозначаются так называемой «меткой ноги вороны», как в этом примере:

Чтобы реализовать связь 1:M, добавьте первичный ключ из «одной» таблицы в качестве атрибута в другую таблицу. Если первичный ключ таким образом указан в другой таблице, он называется внешним ключом. Таблица со стороны связи «1» представляет собой родительскую таблицу для дочерней таблицы на другой стороне.

Связь «многие-ко-многим»

Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь «многие-ко-многим» (M:N). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.

На ER-диаграмме эти связи отображаются с помощью следующих строк:

При проектировании структуры базы данных реализовать такого рода связи невозможно. Вместо этого нужно разбить их на две связи «один-ко-многим».

Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N, можно назвать этот новый объект «sold_products», так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products. Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.

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

Обязательно или нет?

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

Два объекта могут быть взаимозависимыми (один не может существовать без другого).

Рекурсивные связи

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

Лишние связи

Лишние связи — это те, которые выражены более одного раза

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

Так как единственный способ, которым ученикам назначают учителей — это предметы.

Нормализация базы данных

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

В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени (OLTP), должны быть нормализованы.

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

Первая форма нормализации

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

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

Вместо этого во время физического проектирования базы данных разделите данные на несколько таблиц или записей, пока каждая ячейка не будет содержать только одно значение, и дополнительных столбцов не будет. Такие данные считаются разбитыми до наименьшего полезного размера. В приведенной выше таблице можно создать дополнительную таблицу «Реквизиты продаж», которая будет соответствовать конкретным продуктам с продажами. «Продажи» будут иметь связь 1:M с «Реквизитами продаж».

Вторая форма нормализации

Вторая форма нормализации (2NF) предусматривает, что каждый из атрибутов должен полностью зависеть от первичного ключа. Каждый атрибут должен напрямую зависеть от всего первичного ключа, а не косвенно через другой атрибут.

Например, атрибут «возраст» зависит от «дня рождения», который, в свою очередь, зависит от «ID студента», имеет частичную функциональную зависимость. Таблица, содержащая эти атрибуты, не будет соответствовать второй форме нормализации.

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

Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут «название товара» зависит от идентификатора продукта, но не от номера заказа:

  • Номер заказа (первичный ключ);
  • ID товара (первичный ключ);
  • Название товара.

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

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

В соответствии с 3NF, нельзя хранить в таблице любые производные данные, такие как столбец «Налог», который в приведенном ниже примере, напрямую зависит от общей стоимости заказа:

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

Многомерные данные

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

Ключевое поле

Ключевое поле

Это та запись, которая определяет запись в таблице.

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

Сделаем это поле ключевым (на панели задач – ключевое поле) и закроем таблицу.

Это первичный ключ. Для ключевых полей используют тип – счетчик или числовой.

Определим ключевое поле для каждой таблицы аналогично предыдущей.

Книги – код книги.

Издательство – код издательства (тип данных –мастер подстановок – Издательство- выберите поле код и наименование).

Выдача – код выдачи (код читателя – таблица Читатель /код читателя и фамилия/ и код книги – таблица Книги/ код книги и название).

Любое поле можно перетащить мышкой в начало таблицы или в другое нужное место. Ключевые поля обычно ставят на первое месте

Связывание таблиц

Переходим на вкладку – Работа с базами данных – схема данных – появилось окно.

Поочередно нажимаем на название каждой таблицы и закрываем окно.

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

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

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

Аналогично свяжем две другие таблицы.

Откроем таблицу Выдача через конструктор. Добавляем поле Код читателя.

Сохраняем, закрываем.

Теперь Код читателя таблицы Читатель переносим на Код читателя таблицы Выдача.

Ставим везде галочки — создать. Появилась связь (читатель берет много книг).

Теперь свяжем таблица Книги и Выдача. Для этого в таблицу Выдача добавим Код книги. И проделаем те же манипуляции.

Заполнение таблиц

Берем таблицу Читатель. Код читателя ставим на первое место. Нумерация будет автоматическая в этом поле. Вводим остальные данные (не менее 10) и сохраняем правой кнопкой.

Заполняем остальные таблицы по аналогии.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector