• База Данных В Аксессе
• База Данных Access Пример

План: Введение 1. Описание этапов создания реляционной базы данных 1.1 СУБД «ACCESS» 1.2 Создание таблиц 1.3 Установление связей между таблицами в БД 1.4 Создание форм 1.5 Создание запросов 1.6. Создание отчетов Заключение Список литературы Введение В каждой области деятельности создаются собственные базы данных: в социальном обеспечении - по получателям пенсий, в медицине – по диспансерному учету, по льготным лекарствам. Так, для кадровой службы разработана и используется программа «Кадры» специально для работы с личными данными сотрудников.

Построение модели базы данных, исследование предметной области. Создание инфологической.

База данных, имеющаяся в учреждении, позволяет работникам кадровых служб накопленную информацию по сотрудникам оптимально хранить, искать, а также использовать при оформлении различных статистических данных, подготовке отчетов, при решении задач по вопросам повышения квалификации, сертификации. «БАЗА ДАННЫХ (БД) – это совокупность взаимосвязанных и упорядоченных данных, которая обеспечивает их оптимальное использование в определенной области человеческой деятельности».1 В лечебно–профилактических учреждениях Самарской области используется база данных «Кадры», в которой информация хранится в нескольких таблицах.

При установлении между ними связей можно создавать запросы по данным из этих связанных таблиц. В качестве примера рассмотрим этапы создания БД сотрудников в СУБД В МУЗ «Городская поликлиника №3». Описание этапов создания реляционной базы данных 1.1 СУБД « ACCESS » СУБД – это система, позволяющая создавать БД, которая управляет вводом и взаимосвязью данных внутри БД, либо между БД.

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

Управление данными – пароли, корректировка и добавление новых данных. При получении задания необходимо: нажать кнопку «ПУСК»- «Программы» – открыть окно и выбрать пункт «Файл» – открыть.

Выбрать из списка файлов имя БД и нажать ОК 1.2 Создание таблиц Таблицы служат источником данных для запросов, форм, отчетов. Для базы данных «Кадры» создаем таблицы в режиме «Конструктор». Нажимаем кнопку «Создать» на вкладке таблицы (см. 2.1.) и выбираем пункт списка «Конструктор». Рис.1.1 Окно работы с объектами «Access» В открывающемся окне «Конструктор» в столбце «Имя поля» вносим наименования полей создаваемой таблицы. В столбце «Тип данных» - перечисляем типы полей создаваемой таблицы и определяем ключевое поле для связи таблиц по определенному полю. Рис.1.2 создание таблицы в режиме конструктора Например: тип данных для поля «КодСотрудника» – счетчик, а для поля «Фамилия» – текстовый (см.

Чтобы определить ключевое поле необходимо выделить его и нажать инструмент с рисунком ключа. Без ключевых полей невозможно осуществить связывание таблиц. Таким образом, создаем четыре таблицы: - Таблица «Сотрудник» с полями Код сотрудника, Табельный номер, Фамилия, Имя, Отчество, должность (см. Рис.2.3.); - Таблица «СотрАдр» с полями Код сотрудника, Адрес, ДомТелеф, СемПолож (см. 2.4.) - Таблица «Семейное положение» с полями СемПолож и Код; (см. 1.5.) - Таблица «Должность» с полями КодДолжн и Должность (см.

1.6.) рис.1.3 Таблица «Сотрудник» Для более удобной работы при заполнении таблицы «Сотрудник» поле «Должность» имеет подстановку из справочника «Должность» (см. 1.4 Связывание таблиц при помощи подстановки Аналогично в таблице «СотрАдр» поле «Семейное положение» имеет подстановку из справочника «Семейное положение» ( см. Рис.2.6.) рис.1.5 Таблица СотрАдр рис. 1.6 Таблица Семейное положение рис.1.7 Таблица Должность 1.3 Установление связей между таблицами в БД Существует три вида связей: 1 –к – 1; 1 – ко – многим; много – ко – многим. Для установки связей между таблицами на панели инструментов имеется кнопка рис. 1.8 Установление связей между таблицами В поле схемы данных добавляем таблицы, которые будут связаны.

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

Например: таблица «Сотрудник» связана с таблицей «СотрАдр» по КодСотрудника связью 1 – к – 1, а таблица «Семейное положение» связана с таблицей «СотрАдр» связью 1 – ко – многим (см. 1.8.) После установления связей можно создать запрос по данным из этих связанных таблиц. При необходимости тип связи можно легко изменить, удалить ненужную связь или создать новую. 1.4 Создание форм Для удобной работы с БД в ACCESS можно создавать формы. Они могут использоваться для поиска и ввода данных. Формы дают возможность вывести на экран больше данных, нежели таблицы. На закладке «Формы» в окне «Создание объектов» создаем формы в режиме конструктора.

Рис.1.9 Форма « Сотрудники» - режим конструктора Для создания полей в форме используется панель элементов. Для определения свойств формы, полей, заголовков и т.д. Используется окно свойства, где устанавливаются нужные параметры для каждого объекта. В программе «Кадры» имеются пять форм: - Главная (см. 1.10) - Запросы - Отчеты - Сотрудники (см. Рис.1.11) - и подчиненная форма ПФСотрАдр Форма Главная используется для запуска рабочих форм БД и имеет вид: рис.

1.10 Форма Главная Форма Главная имеет четыре кнопки: - Кнопка «Работа с базой данных» - предназначена для работы с формой «Сотрудники»; - Кнопка «Работа по запросам» - предназначена для работы с формой «Запросы»; - Кнопка «Работа с отчетами» предназначена для работы с формой «Отчеты»; - Кнопка «STOP» - предназначена для выхода из БД. В программе «Кадры» для удобства работы создано три формы: - «Сотрудники» - для корректировки, ввода и удаления данных о сотрудниках (рис.1.11); - «Запросы» - для формирования запросов по БД (рис.1.12); - «Отчеты» - для формирования отчетов по запросам (рис.1.13).

1.11 Форма Сотрудники рис.1.12 Форма запросы рис.1.13 Форма Отчеты Форма «Сотрудники» служит для корректировки, ввода и удаления данных о сотрудниках. На форме имеются пять кнопок для удобной работы с БД: - внести новую запись; - сохранить запись; - удалить запись; - найти запись; - выход из формы в Главную форму. Каждой кнопке назначен свой макрос. Например: выход из формы: Рис. 1.14 Макрос для кнопки «выход из формы» Аналогично данной кнопке, остальные кнопки выполняют свои макрокоманды. 1.5 Создание запросов Запрос – это средство отбора данных из одной или нескольких таблиц при помощи определенного пользователем условия.

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

Форма «Запросы» в БД « Кадры» предназначена для работы по запросам. На ней имеются пять кнопок: - «найти по табельному номеру» - выполняется запрос «Поиск сотрудника по табельному номеру». Рис.1.15 Создание запроса в режиме конструктора Запрос создан в режиме конструктора с помощью таблиц «Сотрудники», «СотрАдр» и «Должность» (см рис. В поле условие отбора задан параметр отбора сотрудников по табельному номеру из БД (см.

Рис.2.16) рис. 2.16 Запрос «Поиск по Таб.Ном» В результате запроса открывается форма «ТабНом», где отражается результат (см.рис.1.17).

Рис.1.17 Форма ТабНом - кнопка «Найти по фамилии» предназначена для поиска сотрудника в БД по фамилии и выполняет запрос «Фамилия», который создан аналогично запросу «ТабНом». Запрос создан в режиме конструктора с помощью таблиц «Сотрудники», «СотрАдр» и «Должность» (см. В поле условие отбора задан параметр отбора сотрудников по фамилии из БД. В результате запроса открывается форма «Фамилия» (см.рис.1.18.) рис.

1.18 Форма Фамилия - кнопка «Сортировать по алфавиту» - активизирует запрос сортировки БД по алфавиту с проставлением семейного положения сотрудникам и выдает форму СемПол (см. Запрос создан в режиме конструктора с помощью таблиц «Сотрудники и СотрАдр». В поле сортировка задан параметр по возрастанию, т.е. БД сортируется по алфавиту (см. Рис.1.19 Создание запроса «СемПол»в режиме конструктора рис. 1.20 Форма СемПол - кнопка «Отобрать по должностям» активизирует запрос «Должн», который также создан в режиме конструктора с помощью таблиц «Сотрудники» и «Должность» (см.

Рис 1.21), причем поле «Должность» из таблицы «Сотрудники» не выводится на экран, но по нему выполняется запрос (см. 1.21 Создание запроса «должность» в режиме конструктора рис. 1.22 Запрос на выборку по полю «Должность» В результате запроса на экран выводится форма «Должн» выдающая список сотрудников из БД « Кадры», с соответствующими должностями (см.рис.2.23.) рис.

1.23 Форма «Должн» - кнопка СТОП – выход из формы «Запросы» в Главную форму. 1.6 Создание отчетов Форма «Отчеты» служит для работы с отчетами, на ней имеются четыре кнопки: - кнопка «Списки по должностям»- выводит на экран файл отчета, созданный на основе запроса «Должн». Отчет «Списки по должностям» создан в режиме конструктора (см. Рис.1.24) рис.1.24 Создание отчета в режиме конструктора Данный отчет выводит на просмотр, а при необходимости и на печать Отчет Списки по должностям (см. Рис.1.25) рис.1.25 Отчет «Списки по должностям» - кнопка «Личная карточка сотрудника» - активизирует файл отчета «Фамилия», созданный на основе запроса «Фамилия» и выдает отчет «Личная карточка сотрудника», Отчет создан в режиме «Конструктора» аналогично отчету «Должность».(см. 1.26 Отчет «Личная карточка сотрудника» - кнопка «Списки» сотрудников активизирует файл отчета «Сотруд», созданный на основе запроса «Сотруд», и выдает для просмотра и печати отчет «Список сотрудников». Данный отчет создан в режиме конструктора аналогично предыдущим отчетам (см.рис.1.27.).

Рис.1.27 Экранная форма отчета «Список сотрудников» - кнопка СТОП – выход из формы Отчеты в главную форму. З аключение «Учет трудовых ресурсов и управление ими – необходимая составляющая в общем планировании ресурсов любой организации».2 Однако по мере роста организации для обеспечения оперативной обработки документации по личному составу и эффективной работы с персоналом возникает необходимость в средствах автоматизации.

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

Данная программа имеет удобный пользовательский интерфейс, дешевую себестоимость, небольшие требования к аппаратному обеспечению. Пользователи могут самостоятельно готовить различные отчеты по персоналу предприятия, формировать списки на основании произвольно сформированного запроса. Список литературы 1. «Секретарское дело».

Ежеквартальный журнал. Вейскас «Эффективная работа с Access 97”. Гончаров «Компьютер для менеджера». Самоучитель – СПб: Изд-во «Питер».2000 4. Microsoft Access 2000.

– ВНV – Санкт-Петербург – 1999. Селеста « Access 2000: Учебный курс”.М., 2000. 1 А Гончаров «Компьютер для менеджера». Самоучитель-СПб: Изд-во «Питер» 2000 с.408 2 «Секретарское дело». Ежеквартальный журнал, М., 2001, №1, стр. План: Введение 1.

Описание этапов создания реляционной базы данных 1.1 СУБД «ACCESS» 1.2 Создание таблиц 1.3 Установление связей между таблицами в БД 1.4 Создание форм 1.5 Создание запросов 1.6. Создание отчетов Внимание! Представленная Контрольная работа находится в открытом доступе в сети Интернет, и уже неоднократно сдавалась, возможно, даже в твоем учебном заведении.

Советуем не рисковать. Узнай, сколько стоит абсолютно уникальная Контрольная работа по твоей теме.

Применяется к: Access для Office 365 Access 2016 Access 2013 Access 2010 Access 2007 База данных с правильной структурой обеспечит вам доступ к актуальным и точным сведениям. Поскольку правильная структура важна для выполнения поставленных задач при работе с базой данных, имеет смысл изучить принципы создания баз данных. Это поможет вам создать базу данных, отвечающую вашим потребностям и позволяющую быстро вносить в нее изменения.

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

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

Например, в таблице 'Товары' каждая строка или запись может содержать сведения об одном товаре. Каждые столбец или поле содержат сведения определенного типа об этом товаре, например название или цену. Что такое правильная структура базы данных? В основе процесса создания базы данных лежат определенные принципы.

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

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

предоставление приложению Access данных, необходимых для объединения сведений в таблицах при необходимости;. обеспечение точности и целостности сведений;.

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

Каждый элемент становится полем и отображается в виде столбца в таблице. Например, таблица 'Сотрудники' может содержать такие поля, как 'Фамилия' и 'Дата найма'. Задание первичных ключей Выберите первичный ключ для каждой таблицы. Первичный ключ — это столбец, однозначно определяющий каждую строку. Примеры: 'Код товара' и 'Код заказа'.

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

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

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

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

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

При подготовке списка не старайтесь придать ему законченный вид с первого раза. Записывайте все элементы, которые приходят в голову. Если с базой данных будет работать кто-то еще, попросите их внести свои предложения. Позднее вы сможете скорректировать список. Теперь подумайте, какие типы отчетов или почтовых рассылок будут выполняться на основе сведений из базы данных. Например, это может быть отчет о продажах товаров по регионам или сводный отчет о складских запасах товаров.

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

Какие сведения нужно включить в отчет? Составьте список. То же сделайте для писем и других отчетов, которые предполагается создавать. Продумывая структуру предполагаемых отчетов и почтовых рассылок, вы определите те элементы, которые нужно включить в базу данных. Предположим, вы даете клиентам возможность подписаться на периодическую рассылку обновлений (или отказаться от нее) и хотите распечатать список тех, кто подписался. Для записи этих сведений вы добавляете в таблицу клиентов столбец 'Отправка почты'.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вам также нужно определить, какого рода данные будут храниться в базе данных: отечественные или международные. Например, если вы планируете хранить в базе данных международные адреса, лучше использовать столбец 'Регион', а не 'Страна', потому что в таком столбце можно указывать области внутри своей страны и регионы других стран. Точно так же в поле 'Почтовый индекс' можно будет хранить почтовые индексы разных стран. В списке ниже приведены некоторые советы по определению столбцов. Не включайте вычисляемые данные Не следует хранить в таблицах результаты вычислений. Лучше пусть Access выполняет вычисления всякий раз, как вы захотите увидеть результат.

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

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

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

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

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

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

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

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

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

База Данных В Аксессе

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

Например, показанная ниже форма содержит сведения из нескольких таблиц. Эта форма содержит данные из таблиц клиентов, 2. Сотрудников, 3. И сведений о заказах. Access — это система управления реляционными базами данных.

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

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

Чтобы создать связь 'один ко многим' в структуре базы данных, добавьте первичный ключ на стороне 'один' в таблицу на стороне 'многие' в виде дополнительного столбца или столбцов. Например, в данном случае вы добавляете столбец 'Код поставщика' из таблицы 'Поставщики' в таблицу 'Товары'. Затем Access сможет с помощью кода поставщика в таблице 'Товары' найти поставщика для каждого товара. Столбец 'Код поставщика' в таблице 'Товары' называется внешним ключом.

Внешний ключ — это первичный ключ другой таблицы. Столбец 'Код поставщика' в таблице 'Товары' является внешним ключом, потому что он также является первичным ключом в таблице 'Поставщики'. Создавая пары первичных и внешних ключей, вы создаете основу для объединения сведений из связанных таблиц. Если вы не знаете точно, в каких таблицах должен быть общий столбец, определение связи 'один ко многим' обеспечивает необходимость общего столбца для двух таблиц. Создание связи 'многие ко многим' Рассмотрим связь между таблицами 'Товары' и 'Заказы'. Один заказ может включать несколько товаров.

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

Связь между темами двух таблиц (заказов и товаров) относится к типу 'многие ко многим'. Это проблема. Представьте, что произойдет, если для создания связи между двумя таблицами вы попытаетесь добавить поле 'Код товара' в таблицу 'Заказы'. Чтобы заказ мог включать несколько товаров, вам потребуется несколько записей для каждого заказа в таблице 'Заказы'.

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

Она позволит разбить связь 'многие ко многим' на две связи 'один ко многим'. Вы вставите первичные ключи двух таблиц в третью таблицу. В результате в третьей таблице записываются все экземпляры связи. Каждая запись в таблице 'Сведения о заказах' представляет собой отдельный элемент строки заказа. Первичный ключ этой таблицы состоит из двух полей — внешних ключей таблиц 'Заказы' и 'Товары'. Использовать только поле 'Код заказа' в качестве первичного ключа для этой таблицы нельзя, поскольку в одном заказе может быть несколько элементов строки. Код заказа повторяется для каждого элемента строки, так что это поле не содержит уникальные значения.

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

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

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

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

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

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

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

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

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

Создайте столбец для каждого элемента данных, который нужно отслеживать. Если данные невозможно получить из других столбцов путем вычислений, скорее всего, для них нужен новый столбец. Есть ли ненужные столбцы, значения которых получаются из других полей с помощью вычислений? Если элемент данных можно получить из других столбцов с помощью вычислений (например, цену со скидкой можно вычислять на основе розничной цены), лучше не создавать для него новый столбец. Приходится ли вам неоднократно вводить одни и те же сведения в одной из таблиц? Если да, вам нужно разделить одну таблицу на две и установить между ними связь 'один ко многим'. У вас есть таблицы с большим количеством полей, ограниченным количеством записей и множеством пустых полей в отдельных записях?

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

Усовершенствование таблицы 'Товары' Допустим, все товары в базе данных продаж можно отнести к общим категориям: напитки, приправы и морепродукты. В таблице 'Товары' может быть поле, в котором показана категория каждого товара. Допустим, после проверки и усовершенствования структуры базы данных вы решили хранить вместе с названием категории ее описание. Если вы добавите поле 'Описание категории' в таблицу 'Товары', его придется повторять для каждого товара, относящегося к соответствующей категории.

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

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

Название. Код товара1. Название1. Код товара2.

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

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

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

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

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

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

Это правило применяется, если первичный ключ состоит из нескольких столбцов. Допустим, ваша таблица содержит следующие столбцы, причем столбцы 'Код заказа' и 'Код товара' образуют первичный ключ:. Код заказа (первичный ключ).

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

Допустим, у вас есть таблица со следующими столбцами:. Код товара (первичный ключ).

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

База Данных Access Пример

В данном случае столбец 'Скидка' следует перенести в другую таблицу, в которой столбец 'Рекомендуемая розничная цена' является ключевым.