Модель «сущность-связь»

Для изображения структуры предметной области, отображаемой в БД, используются модели «сущность-связь», или ER-модели (от англ. Entity-Relationship). Чаще всего проектирование БД начинает именно с построения ER-модели. Важнейшими параметрами, которые отображают на этой модели, являются имена таблиц и их атрибутов, состав первичных ключей, связи между таблицами, а также множественность связей.

Основные правила построения модели «сущность-связь»:

• таблицы обозначаются прямоугольниками, в которых указываются их имена;

• имена атрибутов таблиц соединяются с соответствующими прямоугольниками линиями;

• ключевые атрибуты обозначаются символом «*»;

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

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

Модель «сущность-связь» предметной области «КОМПЬЮТЕРНЫЙ МАГАЗИН», по которой можно построить БД, изображена на рис. 2.10.

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

2.4. Этапы проектирования базы данных

Обычно с БД работают две категории исполнителей:

• проектировщики - разработчики структуры таблиц и других объектов БД, включая и средства их безопасности;

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

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

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

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

Прежде всего, следует разработать техническое задание на проектирование БД, в котором указать:

• цель создания БД (ее назначение и предполагаемое использование);

• список исходных данных, с которыми предстоит работать;

• список необходимых выходных данных для управления структурой организации;

• список выходных данных, предоставляемых в другие организации (в вышестоящие структуры, в органы статистического учета, прочие административные и контролирующие организации);

• формы для ввода данных и формы отчетов и другую информацию.

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

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

• включайте все необходимые сведения;

• разбивайте информацию на минимальные логические компоненты (например, имена сотрудников удобно разбить на две поля: «Имя» и «Фамилия», что облегчит сортировку по фамилиям);

• не создавайте поля для данных, состоящих из нескольких элементов (например, если создать в таблице «ПОСТАВЩИКИ» поле «Товары», содержащее перечень всех товаров этого поставщика, будет трудно найти поставщиков, поставляющих конкретный товар);

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

• не создавайте поля, содержащие аналогичные данные (например, если создать в таблице «ПОСТАВЩИКИ» поля «Товар1», «Товар2» и «Товар3», будет трудно найти поставщиков, поставляющих конкретный товар. Кроме того, придется изменять структуру базы данных, если появится поставщик, предлагающий четыре товара. Достаточно будет одного поля для товаров, если поместить это поле в таблицу «ТОВАРЫ», а не в таблицу «ПОСТАВЩИКИ»).

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

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

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

• включайте каждое поле только в одну таблицу;

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

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

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

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

7. Разработкой схемы данных заканчивается «бумажный» этап работы над техническим заданием, после чего можно приступать к непосредственному созданию БД.

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

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

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

• дополнение БД новыми таблицами в связи с появлением новых документов предметной области;

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

• изменение записей, т.е. корректирование данных в случае необходимости.

В процессе ведения БД возможна сортировка данных по заданным критериям, либо фильтрация (отбор) данных с помощью механизма запросов.

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

В MS Access существуют два инструмента, помогающие усовершенствовать структуру БД:

• Мастер анализа таблиц позволяет проанализировать структуру таблицы, предложить подходящие новые структуры и связи, а также разделить таблицу на новые связанные таблицы, если это имеет смысл.

• Анализатор быстродействия исследует всю БД и дает рекомендации по ее улучшению. Мастер может также выполнить эти рекомендации.

При разработке БД следует также обратить внимание на вопросы безопасности.

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

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

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

Операции изменения структуры БД, создания новых таблиц или иных объектов происходят при сохранении файла базы данных. Об этих операциях СУБД предупреждает пользователя. Это глобальные операции.

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