Помогите пожалуйста с вопросом по информатике
Этапы, которых стоит придерживаться при разработке любых баз данных:
1 Разработка и создание отчетов для вывода данных на печать или в файл.
2 Разработка и создание диаграмм.
3 Создание таблиц и связей с ними.
4 Получение примеров внутренних и выходящих документов (файлы формата эксель, ворд,
распечатанные документы).
Голосование за лучший ответ
Остальное не всегда вообще требуется. Особенно п. п. 1, 4.
3. Создание базы данных MS Access
Запускаем приложение Access 2007 . В разделе Новая пустая база данных щёлкаем на пиктограмме Новая база данных. В правой части окна появится информация об имени файла и указана директория для его хранения. По умолчанию имя файла — База данных1.accdb .
Изменить имя файла и путь к директории для хранения файла БД можно в окне «Файл новой базы данных», щёлкнув на пиктограмме «Поиск расположения для размещения базы данных».
Установив имя файла — Деканат_2014.accdb и требуемое имя директории в окне «Файл новой базы данных», надо щёлкнуть по кнопке ОК, окно закроется.
Далее необходимо щёлкнуть на кнопке Создать, чтобы создать пустую базу данных. При создании новой пустой базы данных окно приложения Access 2007 открывается на контекстной вкладке «Режим таблицы». В окне отображается новая пустая таблица с именем Таблица 1 в режиме таблица.
Далее необходимо перейти в режим Конструктор и создать структуру первой таблицы базы данных. Для этого необходимо щёлкнуть по пиктограмме Вид и выбрать режим Конструктор.
Откроется окно Сохранение, в котором надо указать имя Группа студентов и нажать кнопку ОК.
Откроется таблица Группы студентов в режиме Конструктор.
Создаём структуру таблицы Группы студентов. В первую строку колонки «Имя поля» вводим код группы студентов (Код Группы) и нажимаем клавишу Enter.
Курсор переместится в колонку Тип данных.
Access по умолчанию назначает тип данных — Счётчик. Нажимаем клавишу Enter, при этом курсор переместится в колонку Описание, при необходимости вводим описание данных.
Первой строке таблицы (поле Код Группы) Access по умолчанию назначает поле первичного ключа.
Для первичного ключа в свойствах поля устанавливается значение Индексированного поля: Да (Совпадения не допускаются).
Далее заполняем вторую строку (второе поле таблицы), Имя поля — Название, Тип данных — текстовый.
Третья строка: Имя поля — Курс, Тип данных — числовой и четвёртая строка Имя поля — Семестр, Тип данных — числовой.
При этом для имени поля «Название» в разделе Свойства поля необходимо установить размер поля — \(6\).
Ключевое поле — это поле, значения которого однозначно определяет каждую запись в таблице.
Обрати внимание!
Каждая таблица должна содержать, по крайней мере, одно ключевое поле, содержимое которого уникально для каждой записи в этой таблице.
Основные сведения о создании баз данных
База данных с правильной структурой обеспечит вам доступ к актуальным и точным сведениям. Поскольку правильная структура важна для выполнения поставленных задач при работе с базой данных, имеет смысл изучить принципы создания баз данных. Это поможет вам создать базу данных, отвечающую вашим потребностям и позволяющую быстро вносить в нее изменения.
В этой статье приведены рекомендации по планированию базы данных для настольного компьютера. Вы узнаете, как выбирать необходимые сведения, как распределять данные по таблицам и столбцам и как таблицы связаны друг с другом. Прежде чем создавать свою первую базу данных, прочитайте эту статью.
В этой статье
- Некоторые термины, связанные с базами данных
- Что такое правильная структура базы данных?
- Процесс проектирования
- Определение назначения базы данных
- Поиск и упорядочение необходимых сведений
- Распределение данных по таблицам
- Преобразование элементов данных в столбцы
- Задание первичных ключей
- Создание связей между таблицами
- Усовершенствование структуры
- Применение правил нормализации
Некоторые термины, связанные с базами данных
В Access данные упорядочиваются в таблицах, которые представляют собой списки строк и столбцов, напоминающие бухгалтерский блокнот или электронную таблицу. В простой базе данных может быть всего одна таблица. Для большинства баз данных их потребуется несколько. Например, в одной таблице можно хранить сведения о товарах, в другой — о заказах, а в третьей — о клиентах.
Каждую строку правильнее называть записью, а каждый столбец — полем. Запись — это эффективный и согласованный способ объединения сведений о чем-либо. Поле — это отдельный элемент сведений (элементы такого типа есть в каждой записи). Например, в таблице «Товары» каждая строка или запись может содержать сведения об одном товаре. Каждые столбец или поле содержат сведения определенного типа об этом товаре, например название или цену.
Что такое правильная структура базы данных?
В основе процесса создания базы данных лежат определенные принципы. Первый принцип состоит в том, чтобы избегать повторяющихся сведений (также называемых избыточными данными), поскольку они занимают много места и повышают вероятность появления ошибок и несоответствий. Второй принцип провозглашает важность правильности и полноты сведений. Если база данных содержит неправильные сведения, то все отчеты, созданные на основе сведений из этой базы данных, будут содержать неправильные сведения. В итоге решения, которые принимаются на основе этих отчетов, могут оказаться неверными.
Правильная структура базы данных подразумевает:
- распределение сведений по тематическим таблицам для уменьшения количества повторяющихся данных;
- предоставление приложению Access данных, необходимых для объединения сведений в таблицах при необходимости;
- обеспечение точности и целостности сведений;
- соответствие требованиям к обработке данных и созданию отчетов.
Процесс проектирования
Процесс проектирования включает следующие этапы:
- Определение назначения базы данных Помогает подготовиться к остальным этапам.
- Поиск и упорядочение необходимых сведений Соберите сведения всех типов, которые потребуется внести в базу данных, например названия товаров и номера заказов.
- Разделение данных по таблицам Разделите элементы данных по основным темам или группам, например «Товары» и «Заказы». Затем для каждой темы создается таблица.
- Преобразование элементов данных в столбцы Решите, какие сведения будут храниться в каждой таблице. Каждый элемент становится полем и отображается в виде столбца в таблице. Например, таблица «Сотрудники» может содержать такие поля, как «Фамилия» и «Дата найма».
- Задание первичных ключей Выберите первичный ключ для каждой таблицы. Первичный ключ — это столбец, однозначно определяющий каждую строку. Примеры: «Код товара» и «Код заказа».
- Настройка связей между таблицами Проанализируйте все таблицы и определите, как данные одной таблицы связаны с данными других таблиц. Добавьте в таблицы поля или создайте новые таблицы для формирования необходимых связей.
- Усовершенствование структуры Проверьте структуру базы данных на наличие ошибок. Создайте таблицы и добавьте несколько записей с образцами данных. Посмотрите, можно ли получить нужные результаты из таблиц. При необходимости внесите изменения в структуру.
- Применение правил нормализации Примените правила нормализации, чтобы проверить правильность структуры таблиц. При необходимости внесите изменения в таблицы.
Определение назначения базы данных
Рекомендуется записать на бумаге назначение базы данных: ее цель, предполагаемое применение и список пользователей, которые будут с ней работать. Небольшой базе данных для домашнего бизнеса можно дать простое определение, например: «База данных содержит сведения о клиентах и используется для почтовой рассылки и создания отчетов». Для более сложной базы данных, с которой будет работать множество людей, как это часто бывает в больших организациях, определение может состоять из нескольких абзацев, включая время и способы использования ее разными людьми. Идея состоит в том, чтобы детально сформулировать определение, к которому затем можно обращаться в процессе проектирования. Такое определение поможет сосредоточиться на целях и задачах при принятии решений.
Поиск и упорядочение необходимых сведений
Чтобы найти и упорядочить необходимые сведения, начните с имеющейся информации. Например, вы можете записывать заказы на покупку в реестр или хранить сведения о клиентах в бумажных формах в файловом шкафу. Соберите эти документы и выведите список всех типов отображаемых сведений (например, каждое поле, которое вы заполняете в форме). Если у вас нет существующих форм, представьте, что вам нужно создать форму для записи сведений о клиенте. Какую информацию вы бы поместили в форму? Какие поля заполнения вы создадите? Определите и перечислите каждый из этих элементов. Например, предположим, что в настоящее время вы храните список клиентов на карточках индекса. Изучение этих карточек может показать, что каждый карта содержит имя клиента, адрес, город, штат, почтовый индекс и номер телефона. Каждый из этих элементов представляет потенциальный столбец в таблице.
При подготовке списка не старайтесь придать ему законченный вид с первого раза. Записывайте все элементы, которые приходят в голову. Если с базой данных будет работать кто-то еще, попросите их внести свои предложения. Позднее вы сможете скорректировать список.
Теперь подумайте, какие типы отчетов или почтовых рассылок будут выполняться на основе сведений из базы данных. Например, это может быть отчет о продажах товаров по регионам или сводный отчет о складских запасах товаров. Возможно, вы также будете отправлять клиентам стандартные письма, содержащие сведения о продажах или специальных предложениях. Продумайте структуру отчета и представьте себе его внешний вид. Какие сведения нужно включить в отчет? Составьте список. То же сделайте для писем и других отчетов, которые предполагается создавать.
Продумывая структуру предполагаемых отчетов и почтовых рассылок, вы определите те элементы, которые нужно включить в базу данных. Предположим, вы даете клиентам возможность подписаться на периодическую рассылку обновлений (или отказаться от нее) и хотите распечатать список тех, кто подписался. Для записи этих сведений вы добавляете в таблицу клиентов столбец «Отправка почты». В этом поле для каждого клиента можно выбрать значение «Да» или «Нет».
Для отправки клиентам почтовых сообщений требуется записать еще один элемент данных. Если клиент захочет получать почтовые сообщения, вам потребуется его адрес электронной почты. Следовательно, для каждого клиента нужно записать этот адрес.
Имеет смысл создать прототип каждого отчета или списка выходных данных и рассмотреть, какие элементы потребуются для создания отчета. Например, при изучении письма-формы на ум может прийти несколько вещей. Если вы хотите включить правильное приветствие, например строку «Mr.», «Mrs.» или «Ms.», которая начинает приветствие, необходимо создать элемент приветствия. Кроме того, обычно вы можете начать письмо с «Уважаемый мистер Смит», а не «Дорогой. Г-н Сильвестр Смит». Это означает, что вы, как правило, хотите хранить фамилию отдельно от имени.
Важно помнить, что каждый фрагмент сведений целесообразно разделить на минимальные элементы. Например, лучше разделить имя и фамилию, чтобы их удобнее было использовать. В частности, чтобы отсортировать отчет по фамилиям, фамилия должна храниться отдельно. Вообще, если вы хотите выполнять сортировку, поиск, вычисления или отчет на основе элемента данных, следует поместить этот элемент в отдельное поле.
Подумайте о тех вопросах, ответы на которые вам поможет получать база данных. Например, каков объем продаж отдельного товара за последний месяц? Где находятся самые перспективные клиенты? Кто поставляет самый продаваемый товар? Список возможных вопросов поможет вам определить дополнительные элементы данных для записи.
Собрав все нужные сведения, вы можете переходить к следующему этапу.
Распределение данных по таблицам
Чтобы распределить данные по таблицам, выделите основные группы или темы. Например, после поиска и упорядочения сведений для базы данных продаж товаров вы можете получить предварительный список такого вида:
Основные группы здесь — товары, поставщики, клиенты и заказы. Поэтому имеет смысл использовать четыре таблицы: по одной для сведений о товарах, поставщиках, клиентах и заказах. Это не окончательный список, но неплохое начало. Вы можете уточнять список, пока не получите наиболее эффективную структуру.
При первом просмотре предварительной таблицы вам может показаться, что удобнее было бы поместить все сведения в одну таблицу, а не в четыре, как показано на предыдущей иллюстрации. Сейчас вы поймете, почему это плохая идея. Посмотрите на эту таблицу:
В этом случае каждая строка содержит сведения как о продукте, так и о его поставщике. Так как у вас может быть много продуктов от одного поставщика, имя поставщика и сведения об адресе должны повторяться много раз. Это пустая трата места на диске. Запись сведений о поставщике только один раз в отдельную таблицу Поставщики, а затем связывание этой таблицы с таблицей Products — это гораздо лучшее решение.
Вторая проблема с этой структурой возникает тогда, когда нужно изменить сведения о поставщике. Предположим, вам нужно изменить адрес поставщика. Но поскольку адрес указан во многих полях, можно случайно изменить его только в одном поле, забыв о других. Эту проблему можно решить, записав адрес поставщика только в одном поле.
При проектировании базы данных всегда старайтесь записать каждый факт только один раз. Если вы обнаружите, что сведения повторяются (например, адрес конкретного поставщика), поместите их в отдельную таблицу.
Наконец, предположим, что у вас есть только один товар, поставляемый компанией Coho Winery, и вы хотите удалить этот товар, но сохранить имя и адрес поставщика. Как удалить запись о товаре, не потеряв сведений о поставщике? Это невозможно. Поскольку каждая запись содержит сведения и о товаре, и о поставщике, вы не можете удалить их по отдельности. Чтобы разделить эти сведения, необходимо сделать из одной таблицы две: одну — для сведений о товаре, другую —для сведений о поставщике. Тогда удаление записи о товаре не приведет к удалению записи о поставщике.
Выбрав тему для таблицы, проследите, чтобы столбцы в ней содержали сведения только по этой теме. Например, в таблице товаров должны храниться сведения только о товарах. Поскольку адрес поставщика относится к сведениям о поставщиках, а не о товарах, он должен храниться в таблице поставщиков.
Преобразование элементов данных в столбцы
Чтобы определить столбцы таблицы, решите, какие сведения по теме таблицы вам нужно отслеживать. Например, в таблицу клиентов можно включить столбцы «Имя», «Адрес», «Город, область, почтовый индекс», «Отправка почты», «Обращение» и «Адрес электронной почты». Набор столбцов одинаков для всех записей в таблице, поэтому для каждой записи можно хранить одни и те же сведения. Например, столбец «Адрес» содержит адреса клиентов. Каждая запись содержит сведения только об одном клиенте, а поле адреса — его адрес.
После определения первоначального набора столбцов для каждой таблицы вы можете затем уточнять и дополнять их. Например, удобно хранить имя и фамилию клиента в разных столбцах, чтобы проще было выполнять сортировку, поиск и индексирование только по этим столбцам. Адрес также состоит из нескольких компонентов (собственно адреса, города, области, почтового индекса и страны), которые лучше хранить в отдельных столбцах. Например, если вы захотите выполнить поиск, фильтрацию или сортировку по областям, вам потребуется, чтобы сведения об областях хранились в отдельном столбце.
Вам также нужно определить, какого рода данные будут храниться в базе данных: отечественные или международные. Например, если вы планируете хранить в базе данных международные адреса, лучше использовать столбец «Регион», а не «Страна», потому что в таком столбце можно указывать области внутри своей страны и регионы других стран. Точно так же в поле «Почтовый индекс» можно будет хранить почтовые индексы разных стран.
В списке ниже приведены некоторые советы по определению столбцов.
- Не включайте вычисляемые данные Не следует хранить в таблицах результаты вычислений. Лучше пусть Access выполняет вычисления всякий раз, как вы захотите увидеть результат. Предположим, что в отчете о заказанных товарах отображаются промежуточные итоги для заказанных товаров каждой категории. Но в таблице нет столбца для промежуточных итогов. Вместо этого в таблице есть столбец для заказанных товаров, в котором хранится количество единиц каждого товара. Используя эти данные, Access вычисляет промежуточные итоги каждый раз при печати отчета. Сами промежуточные итоги не требуется хранить в таблице.
- Разбивайте информацию на минимальные логические компоненты У вас может возникнуть соблазн иметь одно поле для полных названий или названий продуктов вместе с описаниями продуктов. Если вы объединяете несколько видов информации в поле, получить отдельные факты позже будет трудно. Попробуйте разбить информацию на логические части; например, создайте отдельные поля для имени и фамилии или для названия продукта, категории и описания.
Доработав столбцы с данными во всех таблицах, вы можете перейти к выбору первичного ключа для каждой из них.
Задание первичных ключей
Каждая таблица должна содержать столбец или набор столбцов для однозначного определения каждой строки таблицы. Часто для этого используется уникальный идентификационный номер, например код сотрудника или серийный номер. В базах данных эти сведения называются первичным ключом таблицы. Используя поля первичных ключей, Access быстро связывает данные из нескольких таблиц и сводит их для вас воедино.
Если у вас уже есть уникальный идентификатор для таблицы, например код товара, однозначно определяющий товар в каталоге, вы можете использовать его в качестве первичного ключа таблицы, но только при условии, что значения в этом столбце будут разными для всех записей. В первичном ключе не должно быть повторяющихся значений. Например, не следует использовать в качестве первичного ключа имена людей, поскольку они не уникальны. С большой долей вероятности в одной таблице могут оказаться двое людей с одинаковыми именами.
У первичного ключа всегда должно быть значение. Если в какой-то момент столбец может содержать неназначенное или неизвестное (отсутствующее) значение, его нельзя использовать в качестве компонента первичного ключа.
Всегда выбирайте первичный ключ, значение которого не изменится. В базе данных с несколькими таблицами первичный ключ одной таблицы может использоваться в качестве ссылки в других таблицах. Если первичный ключ изменяется, это изменение необходимо применить ко всем ссылкам на этот ключ. Используя неизменяемый первичный ключ, вы снижаете вероятность нарушения синхронизации с другими таблицами.
Часто в качестве первичного ключа используется произвольный уникальный номер. Например, можно присвоить каждому заказу уникальный номер заказа. Единственное назначение номера заказа — идентифицировать заказ. После назначения он никогда не меняется.
Если вы не имеете в виду столбец или набор столбцов, которые могут стать хорошим первичным ключом, рассмотрите возможность использования столбца с типом данных AutoNumber. При использовании типа данных AutoNumber Access автоматически присваивает вам значение. Такой идентификатор не является фактом; он не содержит фактических сведений, описывающих строку, которую он представляет. Идентификаторы без фактов идеально подходят для использования в качестве первичного ключа, так как они не изменяются. Первичный ключ, содержащий факты о строке, например номер телефона или имя клиента, скорее всего, изменится, так как сама фактическая информация может измениться.
1. Столбец с типом данных «Счетчик» — отличный первичный ключ. Коды товаров никогда не совпадают.
В некоторых случаях первичный ключ таблицы составляется из несколько полей. Например, в таблице «Сведения о заказах», которая содержит элементы строк заказов, первичный ключ может включать два столбца: «Код заказа» и «Код товара». Первичный ключ из нескольких столбцов называется составным.
В базе данных продаж вы можете создать столбец типа «Счетчик» для первичного ключа каждой из таблиц: «Код товара» для таблицы товаров, «Код заказа» для таблицы заказов, «Код клиента» для таблицы клиентов и «Код поставщика» для таблицы поставщиков.
Создание связей между таблицами
Теперь, когда вы распределили сведения по таблицам, вам нужен способ их осмысленного объединения. Например, показанная ниже форма содержит сведения из нескольких таблиц.
1. Эта форма содержит данные из таблиц клиентов,
5. и сведений о заказах.
Access — это система управления реляционными базами данных. В реляционной базе данных сведения распределяются по отдельным тематическим таблицам. Для последующего объединения данных используются связи между таблицами.
Создание связи «один ко многим»
Рассмотрим следующий пример: таблицы Поставщики и продукты в базе данных заказов на продукты. Поставщик может поставлять любое количество продуктов. Из этого следует, что для любого поставщика, представленного в таблице Поставщики, в таблице Products может быть много продуктов. Таким образом, связь между таблицей «Поставщики» и таблицей «Продукты» является связью «один ко многим».
Чтобы создать связь «один ко многим» в структуре базы данных, добавьте первичный ключ на стороне «один» в таблицу на стороне «многие» в виде дополнительного столбца или столбцов. Например, в данном случае вы добавляете столбец «Код поставщика» из таблицы «Поставщики» в таблицу «Товары». Затем Access сможет с помощью кода поставщика в таблице «Товары» найти поставщика для каждого товара.
Столбец «Код поставщика» в таблице «Товары» называется внешним ключом. Внешний ключ — это первичный ключ другой таблицы. Столбец «Код поставщика» в таблице «Товары» является внешним ключом, потому что он также является первичным ключом в таблице «Поставщики».
Создавая пары первичных и внешних ключей, вы создаете основу для объединения сведений из связанных таблиц. Если вы не знаете точно, в каких таблицах должен быть общий столбец, определение связи «один ко многим» обеспечивает необходимость общего столбца для двух таблиц.
Создание связи «многие ко многим»
Рассмотрим связь между таблицами «Товары» и «Заказы».
Отдельный заказ может включать несколько товаров. С другой стороны, один товар может входить в несколько заказов. Таким образом, для каждой записи в таблице «Заказы» может существовать несколько записей в таблицы «Товары». Для каждой записи в таблице Products может быть много записей в таблице Orders. Этот тип отношений называется отношением «многие ко многим», так как для любого продукта может быть много заказов; и для любого заказа, может быть много продуктов. Обратите внимание, что для обнаружения связей «многие ко многим» между таблицами важно учитывать обе стороны связи.
Связь между темами двух таблиц (заказов и товаров) относится к типу «многие ко многим». Это проблема. Представьте, что произойдет, если для создания связи между двумя таблицами вы попытаетесь добавить поле «Код товара» в таблицу «Заказы». Чтобы заказ мог включать несколько товаров, вам потребуется несколько записей для каждого заказа в таблице «Заказы». В этом случае сведения о заказе придется повторять в каждой строке заказа, что может привести к неэффективности структуры таблицы и потере точности данных. Та же проблема возникает при создании поля «Код заказа» в таблице «Товары» — для каждого товара в таблице потребуется несколько записей. Как решить эту проблему?
Ответ заключается в создании третьей таблицы, часто называемой таблицей соединения, которая разбивает связь «многие ко многим» на две связи «один ко многим». Первичные ключи двух таблиц вставляются в третью таблицу. В результате третья таблица записывает каждое вхождение или экземпляр связи.
Каждая запись в таблице «Сведения о заказах» представляет собой отдельный элемент строки заказа. Первичный ключ этой таблицы состоит из двух полей — внешних ключей таблиц «Заказы» и «Товары». Использовать только поле «Код заказа» в качестве первичного ключа для этой таблицы нельзя, поскольку в одном заказе может быть несколько элементов строки. Код заказа повторяется для каждого элемента строки, так что это поле не содержит уникальные значения. Использовать только поле «Код товара» также нельзя, поскольку один товар может входить в разные заказы. Но вместе эти два поля всегда обеспечивают уникальное значение для каждой записи.
В базе данных продаж товаров между таблицами «Заказы» и «Товары» нет прямой связи. Но они связаны опосредованно через таблицу «Сведения о заказах». Связь «многие ко многим» между заказами и товарами представлена в базе данных двумя связями «один ко многим».
- Связь «один ко многим» между таблицами «Заказы» и «Сведения о заказах». В каждом заказе может быть несколько элементов строк, но каждый элемент строки связан только с одним заказом.
- Связь «один ко многим» между таблицами «Товары» и «Сведения о заказах». Каждый товар может быть связан с несколькими элементами строк, но каждый элемент строки связан только с одним товаром.
В таблице Сведения о заказе можно определить все продукты для определенного заказа. Вы также можете определить все заказы для конкретного продукта.
После создания таблицы «Сведения о заказах» список таблиц и полей может выглядеть так:
Создание связи «один к одному»
Еще бывает связь «один к одному». Предположим, вам нужно записать дополнительные сведения о товаре, которые редко используются или применяются к небольшому количеству товаров. Поскольку эти сведения используются редко и в результате их хранения в таблице «Товары» образуются пустые поля для всех товаров, к которым они неприменимы, вам лучше поместить эти сведения в отдельную таблицу. Как и в таблице товаров, в качестве первичного ключа используется код товара. Связь между этой дополнительной таблицей и таблицей «Товары» относится к типу «один к одному». Каждой записи таблицы товаров соответствует одна запись в дополнительной таблице. При определении такой связи у обеих таблиц должно быть общее поле.
Если оказывается, что в базе данных нужно создать связь «один к одному», подумайте, можно ли поместить сведения из двух таблиц в одну таблицу. Если вы этого не хотите по какой-либо причине, например из-за возникновения пустых полей, посмотрите в приведенном ниже списке, как представлять связь в структуре базы данных.
- Если две таблицы объединены одной тематикой, для создания связи можно использовать один и тот же первичный ключ в обеих.
- Если тематика и первичные ключи таблиц различаются, выберите любую из таблиц и вставьте ее первичный ключ в другую таблицу в качестве внешнего ключа.
Определяя связи между таблицами, вы обеспечиваете правильность таблиц и столбцов. При наличии связи «один к одному» или «один ко многим» в таблицах необходимы общие столбцы. При наличии связи «многие ко многим» необходима третья таблица, представляющая связь.
Усовершенствование структуры
После получения необходимых таблиц, полей и связей следует создать и заполнить таблицы примерами данных и попробовать работать с информацией: создавать запросы, добавлять новые записи и т. д. Это помогает выявить потенциальные проблемы, например, может потребоваться добавить столбец, который вы забыли вставить на этапе разработки, или таблица, которую следует разделить на две таблицы, чтобы удалить дублирование.
Проверьте, можно ли использовать базу данных для получения ответов на ваши вопросы. Создайте черновые формы и отчеты и посмотрите, отображаются ли в них нужные данные. Проверьте, нет ли в базе данных повторяющихся данных и при необходимости измените ее структуру.
При внимательном изучении первоначальной базы данных вы наверняка увидите, где ее можно улучшить. Вот некоторые моменты, которые нужно проверить:
- Не забыли ли вы какие-то столбцы? Если да, относятся ли эти сведения к имеющимся таблицам? Если это сведения по другой теме, возможно, потребуется создать еще одну таблицу. Создайте столбец для каждого элемента данных, который нужно отслеживать. Если данные невозможно получить из других столбцов путем вычислений, скорее всего, для них нужен новый столбец.
- Есть ли ненужные столбцы, значения которых получаются из других полей с помощью вычислений? Если элемент данных можно получить из других столбцов с помощью вычислений (например, цену со скидкой можно вычислять на основе розничной цены), лучше не создавать для него новый столбец.
- Приходится ли вам неоднократно вводить одни и те же сведения в одной из таблиц? Если да, вам нужно разделить одну таблицу на две и установить между ними связь «один ко многим».
- У вас есть таблицы с большим количеством полей, ограниченным количеством записей и множеством пустых полей в отдельных записях? Если да, подумайте о том, как изменить структуру таблицы, чтобы в ней было меньше полей и больше записей.
- Каждый элемент данных разделен на минимальные полезные фрагменты? Поместите в отдельный столбец каждый элемент данных, который необходимо использовать для отчетов, сортировки, поиска или вычислений.
- Данные в каждом столбце соответствуют теме таблицы? Если столбец содержит данные, которые не относятся к теме таблицы, их нужно поместить в другую таблицу.
- Представлены ли все связи между таблицами, либо общими полями, либо третьей таблицей? Для связей «один к одному» и «один ко многим» требуются общие столбцы. Для связей «многие ко многим» требуется третья таблица.
Усовершенствование таблицы «Товары»
Допустим, все товары в базе данных продаж можно отнести к общим категориям: напитки, приправы и морепродукты. В таблице «Товары» может быть поле, в котором показана категория каждого товара.
Предположим, что после изучения и уточнения структуры базы данных вы решили сохранить описание категории вместе с ее именем. Если добавить поле «Описание категории» в таблицу Products, необходимо повторить описание каждой категории для каждого продукта, попадающего в категорию. Это не является хорошим решением.
Лучше выделить категории в качестве отдельной темы для отслеживания в базе данных и создать для них отдельную таблицу с собственным первичным ключом. Затем первичный ключ таблицы «Категории» можно добавить в таблицу «Товары» в качестве внешнего ключа.
Связь между таблицами «Категории» и «Товары» относится к типу «один ко многим»: категория может включать несколько товаров, но при этом каждый товар может входить лишь в одну категорию.
Анализируя структуры таблиц, обращайте внимание на повторяющиеся группы. Рассмотрим таблицу со следующими столбцами:
- Код товара
- Название
- Код товара1
- Название1
- Код товара2
- Название2
- Код товара3
- Название3
Здесь каждый товар представлен повторяющейся группой столбцов, которые различаются только номерами в конце имени столбца. Если столбцы пронумерованы таким образом, вам следует пересмотреть структуру таблицы.
У такой структуры есть несколько недостатков. Во-первых, вам придется установить ограничение на количество товаров. После превышения этого ограничения вам потребуется добавить в структуру таблицы новую группу столбцов, а это задача не на пять минут.
Еще одна проблема состоит в том, что для поставщиков, у которых количество товаров меньше максимального, дополнительные столбцы будут оставаться пустыми, занимая лишнее место. Но самый серьезный недостаток такой структуры — усложнение многих задач, таких как сортировка или индексирование таблицы по кодам или названиям товаров.
Если вы видите повторяющиеся группы, посмотрите внимательно, можно ли разделить одну таблицу на две. В приведенном выше примере лучше использовать две таблицы (одну для поставщиков, другую для товаров), связанные с помощью кода поставщика.
Применение правил нормализации
Теперь вы можете применить к структуре своей базы данных правила нормализации данных (иногда их называют просто правила нормализации). Эти правила позволяют проверить правильность структуры таблиц. Процесс применения этих правил к структуре базы данных называется нормализацией базы данных или просто нормализацией.
Нормализацию лучше всего выполнять после внесения в базу данных всех элементов данных и получения предварительной структуры. Цель этого процесса — убедиться в том, что элементы данных распределены по соответствующим таблицам. Правильность самих элементов данных при нормализации не проверяется.
Правила нормализации нужно применять последовательно, проверяя на каждом этапе соответствие структуры базы данных одной из так называемых «нормальных форм». Обычно применяются пять нормальных форм — с первой по пятую. В этой статье рассматриваются первые три формы, поскольку их достаточно для большинства структур баз данных.
Первая нормальная форма
Согласно первой нормальной форме на пересечении строки и столбца в таблице должно находиться одно значение, а не список значений. Например, у вас не может быть поля «Цена» с несколькими ценами. Если представить каждое пересечение строки и столбца как ячейку, эта ячейка должна содержать лишь одно значение.
Вторая нормальная форма
Согласно второй нормальной форме каждый столбец, не являющийся ключевым, должен зависеть от всего ключевого столбца, а не от его части. Это правило применяется, если первичный ключ состоит из нескольких столбцов. Допустим, ваша таблица содержит следующие столбцы, причем столбцы «Код заказа» и «Код товара» образуют первичный ключ:
- Код заказа (первичный ключ)
- Код товара (первичный ключ)
- Название товара
Эта структура не соответствует второй нормальной форме, поскольку название товара зависит от кода товара, но не зависит от кода заказа, то есть этот столбец зависит не от всего первичного ключа. Из этой таблицы нужно удалить столбец «Название товара». Он относится к другой таблице («Товары»).
Третья нормальная форма
Согласно третьей нормальной форме столбцы, не являющиеся ключевыми, должны не только зависеть от всего первичного ключа, но и быть независимыми друг от друга.
Иначе говоря, каждый столбец, не являющийся ключевым, должен зависеть только от первичного ключа. Допустим, у вас есть таблица со следующими столбцами:
- Код товара (первичный ключ)
- Название
- Рекомендуемая розничная цена
- Скидка
Предположим, что скидка зависит от рекомендуемой розничной цены. В этом случае таблица не соответствует третьей нормальной форме, поскольку столбец «Скидка», не являющийся ключевым, зависит от столбца «Рекомендуемая розничная цена», который тоже не является ключевым. Независимость столбцов друг от друга означает, что изменение любого неключевого столбца не должно влиять на другие столбцы. Если вы измените значение в поле «Рекомендуемая розничная цена», соответствующим образом изменится и значение скидки, тем самым нарушая правило. В данном случае столбец «Скидка» следует перенести в другую таблицу, в которой столбец «Рекомендуемая розничная цена» является ключевым.
Описание основных приемов нормализации базы данных
В данной статье, ориентированной на начинающих, объясняется терминология нормализации баз данных. Понимание этой терминологии помогает вести разговор об архитектуре и проектировании реляционных баз данных.
Описание нормализации
Нормализация — это процесс организации данных в базе данных, Она включает в себя создание таблиц и установление связей между ними в соответствии с правилами, разработанными как для защиты данных, так и для повышения гибкости базы данных, устраняя избыточность и несогласованную зависимость.
Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Изменение адреса клиента проще реализовать, если эти данные хранятся только в таблице Customers и нигде в базе данных.
Что такое «несогласованные зависимости»? Хотя пользователю интуитивно понятно искать в таблице Клиенты адрес конкретного клиента, возможно, не имеет смысла искать там зарплату сотрудника, который обращается к данному клиенту. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.
Существует несколько правил нормализации баз данных. Каждое правило называется «обычной формой». Если соблюдается первое правило, база данных, как говорят, находится в «первой нормальной форме». При соблюдении первых трех правил база данных считается в «третьей нормальной форме». Хотя и другие уровни нормализации возможны, третья нормальная форма считается самым высоким уровнем, необходимым для большинства приложений.
Как и во многих формальных правилах и спецификациях, реальные сценарии не всегда позволяют обеспечить идеальное соответствие требованиям. Как правило, для выполнения нормализации приходится создавать дополнительные таблицы, и некоторые клиенты считают это нежелательным. Собираясь нарушить одно из первых трех правил нормализации, убедитесь в том, что в приложении учтены все связанные с этим проблемы, такие как избыточность данных и несогласованные зависимости.
В описаниях ниже приведены соответствующие примеры.
Первая нормальная форма
- Устраните повторяющиеся группы в отдельных таблицах.
- Создайте отдельную таблицу для каждого набора связанных данных.
- Идентифицируйте каждый набор связанных данных с помощью первичного ключа.
Не используйте несколько полей в одной таблице для хранения похожих данных. Например, для слежения за товаром, который закупается у двух разных поставщиков, можно создать запись с полями, определяющими код первого поставщика и код второго поставщика.
Что произойдет при добавлении третьего поставщика? Добавление поля не является ответом; он требует изменений в программе и таблице и не обеспечивает плавное размещение динамического числа поставщиков. Вместо этого можно поместить все сведения о поставщиках в отдельную таблицу Vendors (поставщики) и связать товары с поставщиками с помощью кодов товаров или поставщиков с товарами с помощью кодов поставщиков.
Вторая нормальная форма
- Создайте отдельные таблицы для наборов значений, относящихся к нескольким записям.
- Свяжите эти таблицы с помощью внешнего ключа.
Записи не должны зависеть от чего-либо, кроме первичного ключа таблицы (составного ключа, если это необходимо). Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections. Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.
Третья нормальная форма
- Исключите поля, которые не зависят от ключа.
Значения в записи, которые не являются частью ключа этой записи, не принадлежат в таблице. Если содержимое группы полей может относиться более чем к одной записи в таблице, попробуйте поместить эти поля в отдельную таблицу.
Например, в таблицу Employee Recruitment (наем сотрудников) можно включить адрес кандидата и название университета, в котором он получил образование. Однако для организации групповой почтовой рассылки необходим полный список университетов. Если сведения об университетах будут храниться в таблице Candidates, составить список университетов при отсутствии кандидатов не получится. Таким образом, создайте вместо этого отдельную таблицу Universities и свяжите ее с таблицей Candidates при помощи ключа — кода университета.
ИСКЛЮЧЕНИЕ: Придерживаться третьей нормальной формы, хотя теоретически желательно, не всегда является практическим. Например, для устранения всех возможных зависимостей между полями таблицы Customers придется создать отдельные таблицы для хранения сведений о городах, почтовых индексах, торговых представителях, категориях клиентов и любых других сведений, которые могут дублироваться в нескольких записях. Теоретически нормализация стоит проводить. Однако значительное увеличение числа маленьких таблиц может привести к снижению производительности СУБД или исчерпанию памяти и числа дескрипторов открытых файлов.
Выполнять нормализацию до третьей нормальной формы может быть целесообразно только для часто изменяемых данных. Если при этом сохранятся зависимые поля, спроектируйте приложение так, чтобы при изменении одного из этих полей пользователь должен был проверить все связанные поля.
Другие формы нормализации
Четвертая нормальная форма, также называемая Boyce-Codd нормальной форме (BCNF), и пятая нормальная форма существуют, но редко рассматриваются в практическом проектировании. Игнорирование этих правил может привести к не совсем идеальному дизайну базы данных, но не должно влиять на функциональные возможности.
Нормализация таблицы примеров
Ниже приведен пример нормализации таблицы с вымышленными данными о студентах.
-
Таблица до нормализации:
Student# | Advisor | Adv-Room | Class1 | Class2 | Class3 |
---|---|---|---|---|---|
1022 | Петров | 412 | 101-07 | 143-01 | 159-02 |
4123 | Иванов | 216 | 101-07 | 143-01 | 179-04 |
Student# | Advisor | Adv-Room | Class# |
---|---|---|---|
1022 | Петров | 412 | 101-07 |
1022 | Петров | 412 | 143-01 |
1022 | Петров | 412 | 159-02 |
4123 | Иванов | 216 | 101-07 |
4123 | Иванов | 216 | 143-01 |
4123 | Иванов | 216 | 179-04 |
Student# | Advisor | Adv-Room |
---|---|---|
1022 | Петров | 412 |
4123 | Иванов | 216 |
Таблица Registration:
Student# | Class# |
---|---|
1022 | 101-07 |
1022 | 143-01 |
1022 | 159-02 |
4123 | 101-07 |
4123 | 143-01 |
4123 | 179-04 |
Student# | Advisor |
---|---|
1022 | Петров |
4123 | Иванов |