В этой главе рассматривается таблица данных, которая создает массив, как результат работы функции Таблица (эту функцию нельзя ввести в ячейки вручную). Таблица данных – это быстрый и простой способ выполнить анализ «что если» для сложных взаимосвязанных вычислений на основе формул. Эта функция позволяет изменять одну или две формулы входов и отображение того, что результаты. В главах , и уже были приведены примеры таблиц данных, которые использовались в сочетании с функциями базы данных.
Скачать заметку в формате или , примеры в формате
Анализ «что если» на основе Таблицы с одной переменной
На рис. 21.1 в ячейки В6 используется функция ПЛТ, косвенно зависящая от значения ячейки В2. Если вы измените годовую ставку ставка, функция ПЛТ обновит значение в ячейке В6. Цель состоит в том, чтобы одновременно увидеть, как месячный платеж будет меняться при пяти различных годовых ставках. Хотя это можно сделать путем написания формулы, функция Таблица может быть полезна по двум причинам:
- Таблицы данных работают быстрее, чем решения на основе иных формул.
- Таблицы данных проще в использовании, и время создания формулы сокращается.
Чтобы создать таблицу данных:
- Создайте заголовки А9:В9. В ячейке В10 введите формулу =В6. В ячейки А11:А15 введите значения годовой ставки для анализа. Выделите диапазон А10:В15.
- Пройдите по меню ДАННЫЕ –> Анализ «что если» –> Таблица данных , чтобы открыть диалоговое окно Таблица данных , или нажав и удерживая клавишу Alt, последовательно нажмите Ы, Ё, Т (после нажатия Alt в меню будут появляться подсказки).
- Поскольку вы анализируете влияние годовой ставки, укажите ссылку на нее в поле Подставлять значение по строкам в (рис. 21.2). Вы говорите Таблице данных , заменить значение из ячейки В2 в процессе расчета ПЛТ и вместо него подставить в формулу значения из диапазона А11:А15.
- Нажмите ОК.
Рис. 21.2. Диалоговое окно Таблица данных
Если вы выделите диапазон В11:В15 и взглянете на строку формул, то увидите формулу массива Таблица со ссылкой на ячейку В2. Функцию Таблица нельзя ввести с клавиатуры; она автоматически создается при использовании диалогового окна Таблица данных .
Рис. 21.3. Функцию Таблица можно ввести только с помощью диалогового окна Таблица данных
На рис. 21.4 ячейки в диапазон E3:I3 содержат различные формулы, которые прямо или косвенно ссылаются на число проданных штук (в ячейке В3). Используя Таблицу данные можно выполнить анализ «что если» для пяти формул. Причем все они основываются на одной и той же переменной, расположенной в диапазоне D4:D12.
Рис. 21.4. Одна переменная Таблицы данных может работать на нескольких формулах; чтобы увеличить изображение кликните на нем правой кнопкой мыши и выберите Открыть картинку в новой вкладке
Две переменные в Таблице данных
В следующем примере задача – найти минимальное значение по двум критериям. Для этого используется Таблица данных на основе двух переменных (рис. 21.5). Поместите формулу в левом верхнем углу Таблицы данных (в нашем примере – в ячейке F8), и введите настройте в диалоговом окне Таблица данных , как показано на рис. 21.5.
Рис. 21.5. Таблица данных с двумя переменными
Второй пример (рис. 21.6) вы уже видели в . Там использовалась формула массива. Например, в ячейке F9: =ИНДЕКС($C$2:$C$15;ПОИСКПОЗ($E9&F$8;$A$2:$A$15&$B$2:$B$15;0)). Решение на основе Таблицы данных проще, и работает быстрее.
Рис. 21.6. Использование Таблицы данных , как альтернатива ВПР по двум параметрам
Одно заключительное замечание по поводу Таблицы данных : существует параметр, который позволяет отключить автоматическое обновление Таблиц данных , при этом другие формулы будут пересчитываться автоматически. Если ваш файл «тормозит», пройдите по меню ФАЙЛ –> Параметры , перейдите на вкладку Формулы , и выберите опцию автоматически, кроме таблиц данных (рис. 21.7). Когда вы всё же захотите обновить вычисления в Таблице данных , нажмите F9.
Рис. 21.7. Отключение автоматического вычисления Таблиц данных
1.1. Виды таблиц;
1.2. Виды справочников;
1.3. Виды связок;
2. Обобщение классификации;
2.1. Классификация в табличном виде;
2.2. Классификация в схематичном виде;
3. Некоторые комментарии по применению классификации;
3.1. Применение классификации при нормализации таблиц;
Заключение.
Обоснование статьи и некоторые ключевые понятия
Очень часто присутствовал на обучении дисциплине «Базы данных». Обучался когда-то сам… Как-то даже пришлось проводить целый курс для друзей и знакомых. Во время обучения мною было замечено, что трудности возникают уже на этапе понимания таблиц и того, как ими пользоваться. Многие просто не могли и не могут разработать простейшие базы данных. После более детального рассмотрения такого понятия как таблицы и маленькой классификации, трудности восприятия таблиц в реляционных базах данных почти всегда исчезают. Итак!В данной статье будет рассмотрена маленькая классификация таблиц по признакам целостности и избыточности. Что это значит? Это значит, что будут приведены примеры с описанием, какую структуру таблиц можно делать, чтобы предотвращать (пытаться предотвращать) избыточность и добиваться целостности в реляционных базах данных.
Для понимания дадим краткие определения целостности и избыточности данных:
Целостность данных – это свойство способности по одним данным восстанавливать другие, при этом не теряя семантическое единство этих данных и отношения между ними (между данными).
Избыточность данных – это состояние базы данных, при котором в таблицах присутствуют лишние данные.
Целостность данных может быть нарушена в результате операций модификации данных. Если в базе данных запрещены операции удаления и обновления, то целостность может быть нарушена только в результате операции добавления, а также неправильно написанных скриптов по отображению данных.
1.1. Виды таблиц
Немного углубимся в маленькую классификацию таблиц по видам их структуры. Разделим таблицы на два общих вида. Первым видом будут таблицы-справочники, вторым таблицы-связки.Рисунок 1. Справочники и связки
Информацию в таблицах можно разделить на два вида. На информацию, которая описывает объекты (субъекты), связи и информацию, которая описывает действия, процессы, события, иное.
В справочниках содержатся сведения об объектах и субъектах, связях. В связках содержатся сведения о действиях, процессах, событиях и так далее.
В связках хранятся данные, взятые из таблиц справочников. Поскольку невыгодно повторять одни и те же данные при описании объектов (субъектов) и при описании их взаимодействия, данные об объектах (субъектах) заносятся в справочники, а в таблицах-связках не хранятся данные объектов (субъектов) в чистом виде, а лишь ссылки на них (внешний ключ). Таким образом, в связках хранятся данные по взаимодействию объектов (субъектов) и ссылки на самих объектов (субъектов) (внешний ключ). Эти «ссылки» являются первичными ключами в таблицах справочниках. Но об этом потом…
Отличие справочника от связки выражается в том, что таблицы-справочники могут быть самостоятельными и независимыми (то есть, при чтении данных некоторых справочников можно в целом понять семантику), а таблицы-связки практически никогда.
Справочники могут подразделяться на несколько видов. Это статичные, статично-динамичные и динамичные справочники. Разумеется, вряд ли можно назвать абсолютно статичный справочник, так как в этом мире может измениться всё. Или почти всё.Статичный справочник – справочник, данные об объектах, субъектах, связях в котором либо никогда не подвергаются модификации после первичной модификации, либо настолько редко подвергаются модификации, что этим можно пренебречь.
Примером таких справочников могут служить список месяцев с названиями и номерами, список дней недели, список времён года, список океанов и так далее…
Таблица 1. Пример статичных справочников
– справочник, в котором хранятся данные о связях, если связи носят справочный характер. В таком справочнике могут быть внешние ключи.
Наиболее удачным примером будет таблица с такими медицинскими данными, как вес. Список человек, вес которых измеряется, изменяется не так часто. А вот данные по их весу могут меняться каждый день. Статично-динамичные справочники являются единственными справочниками, где осознанно можно повторять любую информацию. Ещё одним примером может быть справочник окладов по должностям (по коду должности).
Таблица 2. Пример статично-динамичных справочников
Динамичные справочники – это таблицы, данные об объектах, субъектах, связях в которых меняются часто и используются в других таблицах. От статичных справочников отличаются только частотой модификации в них данных.
Примером таких таблиц могут быть списки проектов. На самом деле, данные об открытии или закрытии проектов могут находиться в самом справочнике проектов, что в большинстве случаев неправильно и нарушает целостность. С другой стороны, если хранить историю изменений по открытию и закрытию (приостановке) проектов, то можно получить избыточность данных. Целостность и избыточность данных будут бороться с друг другом ещё долго, также как и зима с летом.
Таблица 3. Пример динамичных справочников
Рисунок 2. Виды справочников
Это справочник-связка (сразу же уточним, что справочник-связка справочником не является, назван так, потому что в нём существуют поля, которые образуют справочник, но в справочник выделены быть не могут). Таблица, в которой хранятся внешние ключи, данные, которые не являются справочными и поля, содержащие данные, которые образуют справочник, но не могут быть выделены в отдельную таблицу-справочник.
Примером справочника-связки будет являться таблица платёжных транзакций. Или таблица с данными о футбольном матче.
Таблица 4. Пример справочника-связки
И связка (да, просто связка). Это таблица в которой хранятся только внешние ключи и данные, которые нельзя отнести к справочным, например дата или значения логических полей.
Примером связки будет являться таблица автоматического логирования терминала обработки данных.
Кстати, легко догадаться, что связки почти нигде не используются, поскольку чаще всего находятся данные, которые могут быть записаны в базу, но не содержаться в справочниках, поэтому невозможно сопоставить им внешний ключ.
Таблица 5. Пример связки
Необходимо пояснить, что это за поля, которые образуют справочник, но не могут быть выделены в отдельную таблицу-справочник. Примером таких полей являются поля «комментарий», «жалоба», «описание», «предложение». Словом, если приводить популярный пример, то поле «сообщение» в таблице базы данных любой социальной сети…
Рисунок 3. Виды связок
2. Обобщение классификации
2.1. Классификация в табличном виде
| Вид таблицы | Описание | Примеры | Плюсы (+) | Минусы(-) |
| Статичный справочник | Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В статичном справочнике должна содержаться информация, которая либо вообще не изменяется, либо изменяется так редко, что этим можно принебречь. На статичный справочник ссылаются (внешний ключ), когда нужно получить названия, обозначения, нормы, количественные или качественные показатели. Иное. | Справочник (наименований и номеров) месяцев. Справочник складов и цехов предприятия. Справочник правил игры. |
Иногда заменяет системные функции СУБД, позволяет более гибко работать с некоторыми данными. В случае, если меняется редко изменяемая информация, предостерегает от серьёзных последствий. | Использование таблицы с любой структурой может замедлять работу, в случае, если таблица заменяет системное хранилише. Приходится писать дополнительные функции и обработки для данной таблицы, которые не всегда правильно оптимизированны. В некоторых случаях невозможно оптимизировать. |
| Статично-динамичный справочник | Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах нельзя использовать внешний ключ этого справочника, однако можно использовать первичный ключ. | Справочник окладов по должностям. Справочник (размеров обуви, веса, роста, размера головы) физиологических параметров. Справочник (менеджеров, компаний) содержащий компании и менеджеров, которые эти компании обслуживают и учитывают. | Справочник, выделенный из справочника-связки, никуда не девается и не имеет никакой реляционной связи, которая позволила бы ему превратиться в статичный или динамичный справочник. А значит, всегда избыточен. | |
| Динамичный справочник | Таблица. Данные из неё берутся часто для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В динамичном справочнике должна содержаться информация, которая часто изменяется. | Справочник клиентов. Справочник поставщиков. Справочник контрагентов. Справочник менеджеров компании. Справочник работников. Справочник студентов. | Позволяет хранить динамичные данные, при этом давая возможность однозначно ссылаться на них. | Чаще всего накопительного типа и не делим, что создаёт определённую избыточность. |
| Справочник-связка | Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах. | Платёжные транзакции. Продажи. Межзаводские перемещения. График перевозок. | Позволяет проводить гибкую нормализацию по схеме «Справочник-связка» = «Связка»+«Статично-динамичный справочник». | Справочник-связка после нормализации превращается в связку и сводит избыточность данных к минимуму, не затрагивая целостность, однако не делим и при архивировании в текущей таблице не подлежит оптимизации. |
| Связка | Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах. Таблица не может содержать кортежей, значения атрибутов в которых являются неделимыми и не уникальными. | Автоматический лог ошибок в программе. Лог запроса сервера. Результаты трассировок. Отчёты о выгрузке и загрузке компонентов. Автоматические отчёты системы безопасности. | Связка сводит избыточность данных к минимуму, не затрагивая целостность. | Накапливаясь, является неделимой таблицей. Сложно оптимизировать. |
Таблица 6. Классификация
2.2. Классификация в схематичном виде
Рисунок 4. Схема классификации таблиц в реляционных базах данных по признакам целостности и избыточности данных
3. Некоторые комментарии по применению классификации
3.1. Применение классификации при нормализации таблиц
Процесс нормализации, если не учитывать некоторые этапы (Но учитывать результаты этих этапов!) - это обычное «дробление» таблиц на более мелкие таблицы с созданием реляционной связи между ними непосредственно или через промежуточные таблицы (связь «Многие ко многим»). Под реляционной связью может не всегда пониматься реляционное отношение!Преобразование динамичного или статичного справочника в статично-динамичный справочник, а справочника-связки в связку, как и статично-динамичного справочника в справочник-связку - это ни что иное, как дробление таблиц. То есть, преобразование одного вида таблиц в другой через показанную выше классификацию в целях избежания избыточности данных - так можно определить нормализацию (один из вариантов определения).
Для примера. Пусть имеется база данных, в которой единственная операция по модификации данных - это добавление. В таком случае становится неэффективным каждый раз при изменении какого либо отдельного атрибута сущности, «копировать» остальные значения атрибутов уже в другой кортеж. В этом случае используются NULL или же создание статично-динамичного справочника, где описывается ряд атрибутов одной семантики или один атрибут, а дублируется лишь внешний ключ с первичным ключом последовательности. Этот же метод может использоваться в традиционной схеме модификации данных с обновлением и удалением данных.
Заключение
Данная классификация была создана мной на основе наблюдений при проектировании баз данных, а также исходя из прочитанной теории по проектированию в реляционных СУБД. Моим друзьям и знакомым, изучающим дисциплину «базы данных» и занимающимся проектированием баз данных, и мне эта классификация достаточно серьёзно упростила «жизнь» и позволила во многих ситуациях заранее выбрать наиболее подходящий и, как оказывалось потом, правильный вид таблицы для хранения в ней тех или иных данных.Классификация может быть расширена разделением существующих видов в ней на подвиды (возможно, даже, добавлением новых видов). Также эта классификация показала, что лучше в некоторых ситуациях не использовать тот или иной вид таблиц. Некоторые виды таблиц из данной классификации лучше использовать реже (динамичные справочники). А некоторые пытаться заменить на другие (справочники-связки на связки).
Надеюсь, кому ни будь ещё поможет эта классификация при освоении дисциплины «Базы данных» и при проектировании баз данных в реляционных СУБД.
Эта статья содержит инструкции по проектированию базы данных. Пользователь научится решать, какие сведения являются необходимыми, и распределять данные по таблицам и столбцам, а также изучит связи таблиц. Прежде чем создавать базу данных или приступать к работе с серьезными базами данных, необходимо ознакомиться с этой статьей.
В этой статье
Терминология, связанная с базами данных
В Microsoft Office Access 2007 данные организуются в таблицы — совокупности строк и столбцов, аналогичные бумагам бухгалтера или книге Microsoft Office Excel 2007. Простая база данных может состоять всего из одной таблицы. Большинство баз данных включают несколько таблиц. Например, в одной таблице могут храниться сведения о продуктах, во второй — сведения о заказах, а в третьей — сведения о клиентах.
Каждая строка называется также записью , а каждый столбец, или тип элемента, называется также полем . Записи позволяют комбинировать данные. Поля представляют собой отдельные элементы данных — типы элементов для каждой строки. Например, в таблице «Продукты» каждая строка или запись содержит сведения об одном продукте. В каждом столбце или поле хранятся определенные данные о продукте, например наименование или цена.
Правильная структура базы данных
В основе процесса создания базы данных лежат определенные принципы. Первый принцип заключается в необходимости исключать повторяющиеся (или лишние) данные, т. к. они занимают место и повышают вероятность возникновения ошибок и неполадок. Второй принцип касается важной роли правильных и полных данных. Если база данных содержит неправильные данные, все отчеты, в которых данные объединяются, будут также содержать неверные сведения. Это может привести к принятию неправильных решений на основе отчетов.
Правильная структура базы данных подразумевает:
- распределение данных по тематическим таблицам в целях сокращения объема повторяющихся данных;
- добавление в Access данных, необходимых для объединения сведений, которые содержатся в таблицах;
- возможность поддержания и отслеживания точности и целостности данных;
- соответствие требованиям к обработке данных и созданию отчетов.
Процесс разработки
Процесс разработки базы данных включает следующие шаги.
- Определение цели создания базы данных
Это позволяет подготовиться к выполнению следующих шагов.
- Поиск и организация необходимых данных
Следует собирать все данные, которые необходимо сохранить в базе данных, например, наименования продуктов и номера заказов.
- Распределение данных по таблицам
Распределите элементы данных по группам или темам, например «Продукты» или «Заказы». Для каждой темы будет создана таблица.
- Преобразование элементов данных в столбцы
Определите, какие данные требуется хранить в каждой таблице. Каждый элемент данных будет введен в отдельное поле и станет столбцом таблицы. Например, таблица «Сотрудники» может содержать такие поля, как «Фамилия» и «Дата найма».
- Задание первичных ключей
Выберите первичные ключи таблиц. Первичный ключ — столбец для однозначного определения каждой записи, например код продукта или заказа.
- Создание связей между таблицами
Проанализируйте все таблицы и определите, как данные одной таблицы связаны с данными других таблиц. Добавьте в таблицы поля или создайте новые таблицы для создания необходимых связей.
- Усовершенствование структуры
Проверьте структуру базы данных на наличие ошибок. Создайте таблицы и добавьте несколько записей с образцами данных. Проанализируйте полученные результаты. Внесите в структуру необходимые изменения.
- Применение правил нормализации
Примените правила нормализации, чтобы проверить правильность структуры таблиц. Внесите в таблицы необходимые изменения.
Определение цели создания базы данных
Целесообразно записать цель создания базы данных на бумаге: задачи, способы использования и список пользователей. Для базы данных небольшого объема для работы на дому можно определить следующую простую цель: «База данных клиентов содержит сведения о клиентах и используется для рассылки сообщений электронной почты и отчетов». При создании более сложной базы данных для большого количества пользователей, например в организации, описание цели может состоять из нескольких параграфов; необходимо указать время и способы использования базы данных различными пользователями. Основная задача — составить подробное описание цели создания базы данных, чтобы иметь возможность обращаться к нему в процессе проектирования. Наличие описания позволяет следовать поставленным целям в процессе принятия решений.
Поиск и организация необходимых данных
Процесс поиска и организации необходимых данных следует начать с записи имеющихся сведений. Например, можно записать заказы из главной книги или сохранить сведения о клиентах из картотеки. Соберите необходимые документы и составьте список типов данных (например, список полей в бланке). Если бланки не используются, представьте, что необходимо создать бланк для записи сведений о клиентах. Какие данные требуется записывать? Какие поля для заполнения необходимо создать? Определите нужные элементы и составьте их список. Предположим, что сведения о клиентах хранятся в картотеке. Анализ карточек позволяет определить, что в них содержатся такие сведения, как имя клиента, адрес, город, область, почтовый индекс и номер телефона. Каждый из этих элементов может стать столбцом таблицы.
При подготовке списка необязательно стремиться придать ему законченный вид с первого раза. Следует записывать все возможные варианты. Если база данных предназначена для нескольких пользователей, попросите их предложить свои варианты. Список можно исправить позднее.
Затем следует определить типы отчетов или рассылок, которые требуется выполнять из базы данных. Например, может потребоваться выполнять отчет о продажах продуктов по регионам или сводный отчет по запасам продуктов. Может также потребоваться создавать письма, адресованные клиентам и содержащие сведения о продажах или специальных предложениях. Продумайте структуру отчета, определите его внешний вид. Какие сведения требуется включить в отчет? Составьте список нужных сведений. Выполните те же действия для писем и других отчетов.
Определение структуры отчетов и рассылок позволяет выявить элементы, которые требуется включить в базу данных. Предположим, что требуется предоставить клиентам возможность подписываться или отменять подписку на регулярную рассылку новостей, а также иметь возможность выводить на печать список подписчиков. Для записи этих сведений в таблицу клиентов следует добавить столбец для отправки сообщений электронной почты. В этом поле можно выбрать вариант «Да» или «Нет» для каждого клиента.
Для отправки клиентам сообщений электронной почты необходимо записать еще один элемент данных. Если клиент согласится получать сообщения электронной почты, потребуется записать его адрес электронной почты. Следовательно, для каждого клиента потребуется сохранить адрес электронной почты.
Удобно создать прототип каждого отчета или списка клиентов для печати и определить, какие элементы данных потребуются для их создания. Например, анализ письма позволяет выявить несколько элементов. Если требуется включить в письмо приветствие — например строку «г.» или «г-жа», — необходимо создать соответствующий элемент. Кроме того, письмо, как правило, начинается со стандартной фразы «Уважаемый г. Егоров», а не с «Уважаемый г. Владимир Егоров». Поэтому фамилию требуется сохранять отдельно от имени.
Важно помнить, что данные необходимо разбивать на минимальные элементы. Имя следует разделять на две части: имя и фамилию, чтобы фамилия была доступна для использования. Например, чтобы выполнить сортировку отчета по фамилиям, необходимо сохранить их в отдельных полях. В целом, если требуется выполнять сортировку, поиск, вычисления или отчеты для отдельных элементов данных, эти элементы следует сохранять в отдельных полях.
Составьте список вопросов, ответы на которые требуется получать с помощью базы данных. Например, каков объем продаж отдельного продукта за последний месяц? Где находятся самые перспективные клиенты? Кто поставляет самый продаваемый продукт? Список возможных вопросов позволяет определить дополнительные элементы данных для записи.
После сбора данных можно переходить к следующему шагу.
Распределение данных по таблицам
Чтобы распределить данные по таблицам, выделите основные группы или темы. Например, после поиска и организации данных для базы данных продаж продуктов может быть составлен следующий список:
Основные группы — продукты, поставщики, клиенты и заказы. Поэтому целесообразно создать четыре таблицы: по одной для сведений о продуктах, поставщиках, клиентах и заказах. Хотя составленный список не является полным, можно начать с этих основных таблиц. Список можно дополнять до тех пор, пока не будет получена нужная структура базы данных.
При первом просмотре предварительного списка элементов может показаться, что целесообразнее поместить все элементы в единую таблицу вместо того чтобы создавать четыре таблицы, как показано в предыдущем примере. В этом разделе объясняется, почему такой подход неэффективен. Ознакомьтесь с таблицей на иллюстрации.
В данном случае каждая строка содержит данные о продуктах и поставщиках. Поскольку один поставщик поставляет различные продукты, его имя и адрес приходится вводить повторно. При этом место на диске используется неэффективно. Более рациональным решением является сохранение сведений о поставщике в отдельной таблице поставщиков и связывание этой таблицы с таблицей продуктов.
Вторая проблема при такой структуре базы данных возникает при необходимости изменить данные о поставщике. Предположим, что требуется изменить адрес поставщика. Поскольку данные о поставщике содержатся в большом количестве строк, пользователь может пропустить некоторые из них. Эту проблему можно также решить с помощью сохранения адреса поставщика в одном расположении.
При разработке базы данных следует стремиться к однократному сохранению каждого элемента данных. Если данные повторяются (например, адрес отдельного поставщика), поместите их в отдельную таблицу.
Наконец, предположим, что компания Coho Winery поставляет только один продукт и его требуется удалить, но при этом сохранить сведения об имени и адресе поставщика. Как удалить запись о продукте, сохранив при этом данные поставщика? Это невозможно. Поскольку каждая строка содержит данные о продукте, а также данные о поставщике, невозможно удалить эти данные отдельно друг от друга. Чтобы разделить эти данные, необходимо создать две таблицы: одну для сведений о продуктах, а вторую — для сведений о поставщиках. В этом случае удаление записи о продукте не будет приводить к удалению данных о поставщике.
После выбора темы для таблицы необходимо отслеживать, чтобы столбцы этой таблицы содержали данные только по этой теме. Например, таблица продуктов должна содержать только сведения о продуктах. Поскольку адрес поставщика относится к данным о поставщиках, а не о продуктах, он должен быть сохранен в таблице поставщиков.
Преобразование элементов данных в столбцы
Чтобы определить столбцы таблицы, следует решить, какие сведения требуется отслеживать для таблицы. Например, в таблицу клиентов можно включить столбцы «Имя», «Адрес», «Город/область/почтовый индекс», «Отправка электронной почты», «Обращение» и «Адрес электронной почты». Все строки содержат одинаковый набор столбцов, поэтому для каждой строки можно сохранять соответствующие сведения. Например, столбец «Адрес» содержит адреса клиентов. Каждая запись содержит сведения только об одном клиенте, и поле адреса содержит адрес этого клиента.
Первоначальный набор столбцов для каждой таблицы можно дополнять новыми столбцами. Например, удобно хранить имя и фамилию клиента в разных столбцах, чтобы облегчить сортировку, поиск и создание индекса. Адрес также состоит из нескольких компонентов: адреса, города, области, почтового индекса и страны, которые лучше хранить в отдельных столбцах. Например, если требуется выполнить поиск, фильтрацию или сортировку по области, необходимо хранить сведения об области в отдельном столбце.
Следует также определить, какого рода данные будут храниться в базе данных: национального или международного уровня. Например, если планируется хранить в базе данных международные адреса, лучше использовать столбец «Регион» вместо «Страна», т. к. в таком столбце можно указывать области внутри своей страны и регионы других стран. Таким же образом в поле Почтовый индекс можно будет хранить почтовые индексы разных стран.
В приведенном ниже списке содержатся несколько советов по созданию столбцов.
- Не включайте в таблицу вычисляемые данные
Не следует хранить в таблицах результаты вычислений. Вместо этого можно выполнять вычисления в Access при каждой необходимости получить результат. Предположим, что в отчете о заказанных продуктах отображаются промежуточные итоги для заказанных продуктов каждой категории. Однако таблица не содержит столбец для промежуточных итогов. Вместо этого таблица включает столбец для заказанных продуктов, в котором хранится количество каждого продукта. С помощью этих данных Access высчитывает промежуточные итоги при каждой печати отчета. Сами промежуточные итоги не хранятся в таблице.
- Разбивайте информацию на минимальные логические компоненты
Может показаться, что лучше создавать единые поля для сохранения полных имен или названий продуктов вместе с их описаниями. Однако объединение различных данных в одном поле затрудняет их дальнейшее извлечение. Следует разбивать информацию на логические компоненты. Например, можно создать отдельные поля для имени и фамилии или для названия, категории и описания продукта.
После создания столбцов в таблицах можно выбрать первичный ключ для каждой таблицы.
Задание первичных ключей
Каждая таблица должна содержать столбец или набор столбцов для однозначного определения каждой строки таблицы. Как правило, в этих целях используется уникальный идентификационный номер, например код сотрудника или серийный номер. В базе данных такие сведения носят название первичного ключа таблицы. В Access первичные ключи служат для быстрого связывания данных из нескольких таблиц и их отображения для пользователя.
Если в таблице имеется уникальный идентификатор, например номер продукта, который однозначно определяет каждый продукт в каталоге, его можно использовать в качестве первичного ключа таблицы, но значения этого столбца должны быть различными для всех записей. Первичный ключ не должен содержать повторяющихся значений. Например, не следует использовать в качестве первичного ключа имена людей, т. к. они не являются уникальными. В одной таблице могут существовать две записи с одинаковыми именами.
Первичный ключ должен всегда иметь значение. Если столбец допускает неназначенное или отсутствующее значение, его не следует использовать в качестве компонента первичного ключа.
Значение первичного ключа не должно меняться. В базе данных с несколькими таблицами первичный ключ одной таблицы может использоваться в качестве ссылки в других таблицах. Если первичный ключ изменяется, это изменение необходимо применить ко всем ссылкам на этот ключ. Благодаря использованию первичного ключа с постоянным значением снижается вероятность нарушения синхронизации с другими таблицами.
Часто в качестве первичного ключа используется произвольное уникальное числовое значение. Например, каждому заказу можно присвоить уникальный номер для однозначного определения заказа. Этот номер не подлежит изменению.
Если не удается выбрать столбец или набор столбцов для использования в качестве первичного ключа, можно использовать столбец с типом данных «Счетчик». При использовании такого столбца в Access автоматически назначаются значения. Такой код не содержит сведений; в нем нет описания строки, которую он представляет. Бессодержательные коды идеально подходят для использования в качестве первичного ключа, т. к. они не изменяются. Первичный ключ, содержащий фактические данные о строке, например номер телефона или имя клиента, более подвержен изменениям, т. к. фактические сведения могут измениться.
Столбец с типом данных «Счетчик» — удобный первичный ключ. Коды продуктов никогда не совпадают.
В некоторых случаях в качестве первичного ключа таблицы требуется использовать два и более полей. Например, для таблицы сведений о заказах, в которой хранятся элементы строк для заказов, в первичном ключе можно использовать два столбца: код заказа и код продукта. Первичный ключ из нескольких столбцов называется составным.
В базе данных продаж можно создать столбец счетчика для первичного ключа всех таблиц: «КодТовара» для таблицы товаров, «КодЗаказа» для таблицы заказов, «КодКлиента» для таблицы клиентов и «КодПоставщика» для таблицы поставщиков.
Создание связей между таблицами
После распределения данных по таблицам необходимо получить возможность объединять их. Например, изображенная ниже форма включает сведения из нескольких таблиц.
Эта форма содержит данные из таблицы клиентов,
Сотрудников,
Заказов,
Продуктов
И сведений о заказах.
Access — это система управления реляционными базами данных. В реляционной базе данных сведения распределяются по отдельным, тематически организованным таблицам. Для объединения данных используются связи между таблицами.
Создание отношения «один-ко-многим»
Рассмотрим следующий пример: база данных заказов продуктов содержит таблицы поставщиков и продуктов. Поставщик может поставлять любое количество продуктов. Следовательно, для каждого поставщика из таблицы поставщиков в таблице продуктов может содержаться большое количество продуктов. Поэтому связь между таблицей поставщиков и таблицей продуктов представляет собой отношение «один-ко-многим».
Чтобы создать отношение «один-ко-многим» в структуре базы данных, добавьте первичный ключ на стороне «один» в таблицу на стороне «многие» в виде дополнительного столбца. В данном примере необходимо добавить столбец кода поставщика из таблицы поставщиков в таблицу продуктов. После этого Access сможет использовать код поставщика из таблицы продуктов для поиска поставщика каждого продукта.
Столбец кода поставщика в таблице продуктов называется внешним ключом. Внешний ключ — это первичный ключ другой таблицы. Столбец кода поставщика в таблице продуктов является внешним ключом, т. к. он является также первичным ключом таблицы поставщиков.
Основой для связывания таблиц является объединение первичных и внешних ключей в пары. Если не удается определить таблицы с общим столбцом, создание отношения «один-ко-многим» обеспечивает необходимость общего столбца для двух таблиц.
Создание отношения «многие-ко-многим»
Рассмотрим связь между таблицами продуктов и заказов.
Один заказ может включать несколько продуктов. С другой стороны, отдельный продукт может содержаться в нескольких заказах. Следовательно, для каждой записи таблицы заказов может существовать несколько записей в таблице продуктов, и наоборот. Такой тип связи называется отношением «многие-ко-многим». Обратите внимание, что для обнаружения отношения «многие-ко-многим» между таблицами важно рассмотреть обе стороны.
Темы двух таблиц — заказы и продукты — связаны отношением «многие-ко-многим». Это проблема. Представьте, что произойдет, если создать связь между двумя таблицами путем добавления поля с кодом продукта в таблицу заказов. Чтобы заказ мог содержать несколько продуктов, каждый заказ в таблице должен включать несколько записей. В этом случае сведения о заказе должны повторяться в каждой строке заказа, что может привести к неэффективности структуры таблицы и неточности данных. Такая же трудность возникает при создании поля с кодом заказа в таблице продуктов — для каждого продукта в таблице существует несколько записей. Как решить эту проблему?
Решением является создание третьей, связующей, таблицы, в которой отношение «многие-ко-многим» разбивается на два отношения «один-ко-многим». Первичные ключи двух таблиц вставляются в третью таблицу. В результате в третьей таблице сохраняются все экземпляры отношения.
Каждая запись в таблице сведений о заказах представляет собой отдельный элемент строки заказа. Первичный ключ таблицы состоит из двух полей — внешних ключей таблиц заказов и продуктов. Невозможно использовать для первичного ключа этой таблицы только поле с кодом заказа, т. к. один заказ может содержать много элементов строк. Код заказа повторяется для каждого элемента строки, поэтому это поле не содержит уникальных значений. Невозможно также использовать только поле с кодом продукта, т. к. один продукт может входить в несколько заказов. Однако использование двух полей позволяет получить уникальное значение для каждой записи.
В базе данных продаж продуктов таблицы заказов и продуктов не имеют непосредственной связи. Они связаны опосредованно через таблицу сведений о заказах. Отношение «многие-ко-многим» между заказами и продуктами представлено в базе данных двумя отношениями «один-ко-многим»:
- Таблицы заказов и сведений о заказах связаны отношением «один-ко-многим». Каждый заказ содержит несколько элементов строк, но каждый элемент связан только с одним заказом.
- Таблицы продуктов и сведений о заказах связаны отношением «один-ко-многим». Каждый продукт может быть связан с несколькими элементами строк, но каждый элемент связан только с одним продуктом.
В таблице сведений о заказах можно определить продукты для отдельного заказа. Можно также определить заказы для отдельного продукта.
После создания таблицы сведений о заказах список таблиц и полей может выглядеть следующим образом:
Создание отношения «один-к-одному»
Следующий тип отношений — отношение «один-к-одному». Предположим, что требуется сохранить дополнительные сведения о продукте, которые редко используются или применимы к небольшому числу продуктов. Поскольку эта информация используется редко и ее сохранение в таблице продуктов требует создания дополнительного пустого поля для всех продуктов, к которым она не применима, лучше поместить эту информацию в отдельную таблицу. Как и в таблице продуктов, в качестве первичного ключа используется код продукта. Дополнительная таблица и таблица продуктов связаны отношением «один-к-одному». Для каждой записи таблицы продуктов в дополнительной таблице существует одна запись. При определении отношения такого типа обе таблицы должны содержать одно поле.
Если возникает необходимость в создании в базе данных отношения «один-к-одному», рассмотрите возможность объединения данных в одну таблицу. Если этот вариант неприемлем, например по причине возникновения пустых полей, используйте приведенный ниже список для определения отношения в структуре базы данных.
- Если таблицы объединены одной темой, отношение можно создать посредством использования общего первичного ключа.
- Если тематика и первичные ключи таблиц различаются, следует выбрать любую из таблиц и вставить ее первичный ключ в другую таблицу в качестве внешнего ключа.
Определение связей между таблицами позволяет обеспечить правильность таблиц и столбцов. При наличии отношения «один-к-одному» или «один-ко-многим» таблицы должны содержать общие столбцы. При наличии отношения «многие-ко-многим» требуется третья таблица.
Усовершенствование структуры
После создания необходимых таблиц, полей и связей следует заполнить таблицы образцами данных и выполнить с ними различные операции: создание запросов, добавление новых записей и т. д. Это позволит выявить возможные проблемы — например, может потребоваться добавить дополнительный столбец или разбить одну таблицу на две для исключения повторяющихся данных.
Проверьте, можно ли использовать базу данных для получения ответов на нужные вопросы. Создайте черновые формы и отчеты и убедитесь, что в них отображаются нужные данные. Проверьте базу данных на наличие повторяющихся данных и при необходимости удалите эти данные.
В начале работы с базой данных можно выявить области для усовершенствования ее структуры. Можно обратить внимание на следующие пункты:
- Отсутствие необходимых столбцов. Если некоторые столбцы отсутствуют, следует определить, в какую из существующих таблиц можно добавить данные. Если данные относятся к другой теме, может потребоваться дополнительная таблица. Создайте столбец для каждого элемента данных, который требуется отслеживать. Если данные невозможно получить из других столбцов путем вычислений, может потребоваться новый столбец.
- Наличие столбцов, данные которых можно получать из существующих полей путем вычислений. Если данные можно получать из других столбцов путем вычислений — например, цену со скидкой можно вычислять на основе розничной цены — рекомендуется избегать использования дополнительных столбцов.
- Наличие многократно повторяющихся данных в таблицах. В этом случае следует разделить таблицу на две таблицы и связать их отношением «один-ко-многим».
- Наличие таблиц с большим количеством полей, ограниченным количеством записей и пустыми полями в отдельных записях. В этом случае может потребоваться изменить структуру таблицы, чтобы сократить число полей и увеличить число записей.
- Разбиение каждого элемента данных на минимальные компоненты. Если элемент данных требуется использовать для отчетов, сортировки, поиска или вычислений, его следует поместить в отдельный столбец.
- Наличие в столбце данных, относящихся к теме таблицы. Если столбец содержит данные, которые не относятся к теме таблицы, их следует поместить в другую таблицу.
- Наличие связей между таблицами, представленных общими полями или третьей таблицей. Для создания отношений «один-к-одному» и «один-ко-многим» требуются общие столбцы. Для создания отношения «многие-ко-многим» требуется третья таблица.
Усовершенствование структуры таблицы продуктов
Предположим, что все продукты в базе данных можно разделить на несколько общих категорий, например напитки, приправы или рыбные продукты. Таблица продуктов может содержать поле, в котором указана категория продукта.
Предположим, что после анализа и усовершенствования структуры базы данных было решено сохранять не только имя категории продуктов, но и ее описание. Если добавить поле с описанием категории в таблицу продуктов, описание придется повторять для каждого продукта в отдельной категории, а это решение не является рациональным.
Более рациональный подход — выделить категорию как отдельную тему для отслеживания в базе данных, создать отдельную таблицу с собственным первичным ключом. Затем первичный ключ таблицы категорий можно добавить в таблицу продуктов в качестве внешнего ключа.
В процессе анализа структуры таблиц следует выявлять повторяющиеся группы. Предположим, что таблица содержит следующие столбцы:
- Код продукта
- Код продукта1
- Код продукта2
- Код продукта3
В данном случае продукты — повторяющиеся группы столбцов, отличные друг от друга только номером в имени столбца. Если столбцы пронумерованы таким образом, следует пересмотреть структуры таблицы.
Такая структура имеет несколько недостатков. Прежде всего, существует верхний предел для числа продуктов. После превышения этого предела в таблицу необходимо добавить новую группу столбцов, а эта задача сложна для выполнения.
Следующий недостаток заключается в том, что если число продуктов для отдельного поставщика меньше максимального, некоторые столбцы будут оставаться пустыми. Но самый серьезный недостаток такой структуры — усложнение многих задач, таких как сортировка или создание индекса таблицы по коду или наименованию продукта.
При наличии повторяющихся групп следует рассмотреть возможность разбиения одной таблицы на две. В приведенном выше примере лучше создать две таблицы: одну — для поставщиков, а вторую — для продуктов, и связать их с помощью кода поставщика.
Применение правил нормализации
Следующим этапом создания базы данных может стать применение правил нормализации данных (или просто правил нормализации). Эти правила позволяют проверить правильность структуры таблиц. Процесс применения этих правил к структуре базы данных называется нормализацией базы данных или просто нормализацией.
Нормализацию рекомендуется выполнять после внесения в базу данных всех элементов данных и создания предварительной структуры. Цель этого процесса — проверить правильность распределения элементов данных по таблицам. Однако нормализация не позволяет проверить правильность самих элементов данных.
Применение правил нормализации выполняется последовательно; на каждом этапе проверяется соответствие базы данных одной из т. н. нормальных форм. Существует пять нормальных форм. В этой статье описываются первые три формы, поскольку их применения достаточно для большинства баз данных.
Первая нормальная форма
Первая нормальная форма содержит правило о том, что каждая ячейка на пересечении строки и столбца в таблице должна содержать отдельное значение, а не список значений. Например, поле «Цена» должно содержать лишь одно значение цены. Если на пересечении строки и столбца находится ячейка, она должна содержать лишь одно значение.
Вторая нормальная форма
Вторая нормальная форма содержит требование о том, что каждый столбец, не входящий в ключ, должен находиться в зависимости от всего ключевого столбца, а не от его части. Это правило применимо в том случае, если первичный ключ состоит из нескольких столбцов. Предположим, что таблица, в которой первичный ключ состоит из столбцов с кодом заказа и кодом продукта, содержит следующие столбцы:
- Код заказа (первичный ключ)
- Код продукта (первичный ключ)
- Имя продукта
Такая структура не соответствует второй обычной форме, т. к. имя продукта зависит от кода продукта, но не зависит от кода заказа; следовательно, этот столбец зависит лишь от части первичного ключа. Столбец с именем продукта следует удалить из таблицы. Он должен быть включен в другую таблицу (таблицу продуктов).
Третья нормальная форма
Третья нормальная форма содержит требование о том, что столбцы, не являющиеся ключевыми, должны не только зависеть от всего первичного ключа, но и быть независимыми друг от друга.
Другими словами, каждый столбец, не являющийся ключевым, должен зависеть только от первичного ключа. Предположим, что таблица содержит следующие столбцы:
- Код продукта (первичный ключ)
- Рекомендуемая розничная цена
- Скидка
Предположим, что скидка зависит от рекомендуемой розничной цены. В этом случае таблица не соответствует требованию третьей обычной формы, т. к. столбец скидки, не являющийся ключевым, зависит от другого столбца, не являющегося ключевым (столбца рекомендуемой розничной цены). Требование о независимости столбцов друг от друга означает, что изменение любого неключевого столбца не должно влиять на другие столбцы. Но при изменении значения в столбце розничной цены значение скидки изменялось бы соответствующим образом, нарушая правило. Поэтому в данном случае столбец скидки следует перенести в другую таблицу, в которой столбец розничной цены является ключевым.
Дополнительные сведения
Дополнительные сведения о проектировании баз данных см. в следующих книгах.
- Hernandez, Michael J. Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design, Second Edition. Addison-Wesley Professional. 2003.
- Fleming, Candace C. von Halle, Barbara. Handbook of Relational Database Design. Addison-Wesley Professional. 1989.
- Riordan, Rebecca M. Designing Effective Database Systems. Addison-Wesley Professional. 2005.
Применимо к Access 2007 и выше
Прежде чем создавать с помощью Microsoft Access таблицы, формы и другие объекты, составляющие базу данных, необходимо уделить время этапам проектирования базы данных.
Основными этапами проектирования базы данных являются:
· определение цели создания базы данных;
· определение таблиц, которые должна содержать база данных;
· определение необходимых в таблице полей;
· определение полей с уникальными значениями в каждой записи;
· определение связей между таблицами.
Определение цели создания базы данных
На первом этапе проектирования базы данных необходимо определить назначение базы данных, как она будет использоваться, и какие сведения она должна содержать. Зная это, можно определить, какие сведения будут храниться в таблицах и в полях таблиц. База данных должна отвечать требованиям тех, кто будет непосредственно с ней работать. Для этого нужно определить темы, которые должна покрывать база данных, отчеты, которые она должна выдавать, проанализировать документы, которые в настоящий момент используются для записи данных, сравнить создаваемую базу данных с хорошо спроектированной, подобной ей базой. Целью данной базы данных является получение как можно больше сведений о клиенте, а именно, фамилию, имя, отчество, адрес, телефон, а также услугу, которую необходимо выполнить для данного клиента.
Определение таблиц, которые должна содержать база данных
Определение необходимых в базе данных таблиц может оказаться самым непростым этапом процесса проектирования базы данных, поскольку результаты, которые должна выдавать база данных -- отчеты, формы и т.п. -- не всегда дают полное представление о структуре таблиц, по которым они создаются. Для проектирования таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге. При разработке таблиц рекомендуется руководствоваться следующими основными принципами:1) Сведения не должны дублироваться в таблице или между таблицами. В этом отношении таблицы в реляционной базе данных отличаются от таблиц в приложениях, работающих с таблицами в текстовом формате, таких как редакторы электронных таблиц. Данные, хранящиеся только в одной таблице, обновляются только в этой таблице. Это более эффективно и, кроме того, исключает возможность дублирования записей, содержащих разные сведения. Например, адрес и номер телефона каждого клиента достаточно сохранить один раз, в одной таблице.2) Каждая таблица должна содержать информацию только на одну тему. Когда каждая таблица содержит сведения только по одной теме, со сведениями по каждой теме можно работать независимо от остальных тем. Например, адрес клиента хранится отдельно от заказов этого клиента, что позволяет удалить один запрос, сохранив сведения о клиенте. В данной базе данных содержится семь таблиц: жилищная организация, жилой дом, квартира, жильцы, информация о жильцах, услуга, информация о выполненной услуге.
Определение необходимых в таблице полей
Каждая таблица содержит сведения по конкретной теме, а каждое поле в таблице содержит конкретный факт по теме таблицы. Например, таблица «Жильцы» содержит поля фамилия, имя, отчество, а конкретный факт это конкретный человек, например, Иванов Иван Иванович.
При составлении полей для каждой таблице необходимо учитывать следующие основные принципы:
· Каждое поле должно быть связано с темой таблицы;
· Таблица должна содержать все необходимые сведения;
· Данные следует разбить на наименьшие логические единицы.
Определение полей с уникальными значениями в каждой записи
Для связывания в Microsoft Access сведений, хранящихся в разных таблицах - например, для связывания паспортистки со всеми ее клиентами - каждая таблица базы данных должна содержать поля или набор полей, однозначно определяющих каждую запись. Такое поле или набор полей называют первичным ключом. Например, таблица “Жилищная организация” связана с таблицей “Жилой дом” связью “один ко многим”, следовательно, таблица “Жилой дом” имеет вторичный ключ “Номер организации”, а первичный ключ “Номер дома”.
Определение связей между таблицами
После того, как разбили сведения на таблицы и определили ключевые поля необходимо выбрать способ, которым Microsoft Access будет вновь объединять связанные сведения. Для этого следует определить связи между таблицами базы данных Microsoft Access. Связи бываю: один ко многим, много ко многим (реже используется).
