Проектирование баз данных. Основные этапы разработки БД

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

Процесс проектирования базы данных

Надлежащим образом структурированная база данных:

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

Разработка БД включает в себя следующие этапы:

1. Анализ требований или определение цели базы данных;
2. Организация данных в таблицах;
3. Указание первичных ключей и анализ связей;
4. Нормализация таблиц.

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

Анализ требований: определение цели базы данных

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

Вот несколько способов сбора информации перед созданием базы данных:

• Опрос людей, которые будут ее использовать;
• Анализ бизнес-форм, таких как счета-фактуры, расписания, опросы;
• Рассмотрение всех существующих систем данных (включая физические и цифровые файлы ).

Начните со сбора существующих данных, которые будут включены в базу. Затем определите типы данных, которые нужно сохранить. А также объекты, которые описывают эти данные. Например:

Клиенты

• Адрес;
• Город, штат, почтовый индекс;
• Адрес электронной почты.

Товары

• Название;
• Цена;
• Количество в наличии;
• Количество под заказ.

Заказы

• Номер заказа;
• Торговый представитель;
• Дата;
• Товар;
• Количество;
• Цена;
• Стоимость.

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

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

Структура базы данных: построение блоков

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

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

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

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

• CHAR — конкретная длина текста;
• VARCHAR — текст различной длины;
• TEXT — большой объем текста;
• INT — положительное или отрицательное целое число;
• FLOAT , DOUBLE — числа с плавающей запятой;
• BLOB — двоичные данные.

Некоторые СУБД также предлагают тип данных Autonumber , который автоматически генерирует уникальный номер в каждой строке.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лишние связи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правила целостности данных

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

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

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

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

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

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

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

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

Расширенные свойства

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

SQL и UML

Унифицированный язык моделирования (UML ) — это еще один визуальный способ выражения сложных систем, созданных на объектно-ориентированном языке. Некоторые из концепций, упомянутых в этом руководстве, известны в UML под разными названиями. Например, объект в UML известен, как класс.

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

Системы управления базами данных

Структура проектируемой базы данных зависит от того, какую СУБД вы используете. Некоторые из наиболее распространенных:

• Oracle DB ;
• MySQL ;
• Microsoft SQL Server ;
• PostgreSQL ;
• IBM DB2 .

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

Перевод статьи «Database Structure and Design Tutorial » дружной командой проекта

В первой статье из цикла «Данные в WordPress» я привела обзорные сведения об использовании реляционных баз данных в WordPress: какие таблицы используются, и какие данные…

Для защиты конфиденциальных данных в MySQL 5.7 появилась возможность шифрования данных с помощью движка InnoDB. В этой статье я объясню принципы шифрования баз данных,…

1. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

1.1. Реляционная база данных и ее структура

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

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

Строки таблицы называются записями . Все записи таблицы имеют одинаковую структуру – они состоят изполей (элементов данных), в которых хранятся атрибуты объекта (рис. 1). Каждое поле записи содержит одну характеристику объекта и представляет собой заданный тип данных (например, текстовая строка, число, дата). Для идентификации записей используется первичный ключ.Первичным ключом называется набор полей таблицы, комбинация значений которых однозначно определяет каждую запись в таблице.

Рис. 1. Названия объектов в таблице

Для работы с данными используются системы управления базами данных (СУБД). Основные функции СУБД:

– определение данных (описание структуры баз данных);

– обработка данных;

– управление данными.

Разработка структуры БД – важнейшая задача, решаемая при проектировании БД. Структура БД (набор, форма и связи ее таблиц) – это одно из основных проектных решений при создании приложений с использованием БД. Созданная разработчиком структура БД описывается на языке определения данных СУБД.

Любая СУБД позволяет выполнять следующие операции с данными:

– добавление записей в таблицы;

– удаление записей из таблицы;

– обновление значений некоторых полей в одной или нескольких записях в таблицах БД;

– поиск одной или нескольких записей, удовлетворяющих заданному условию.

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

«язык структурированных запросов» (SQL – Structured Query Language).

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

1.2. Этапы проектирования реляционной базы данных

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

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

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

На заключительном (третьем) этапе логическая структура БД преобразуется в физическую с учетом аспектов производительности. Элементы данных на этом этапе получают атрибуты и определяются как столбцы в таблицах выбранной для реализации БД СУБД.

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

1.2.1. Определение требований

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

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

Таблица 1

Словарь данных для приложения БД менеджера турфирмы

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

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

Функциональное описание для приложения БД менеджера турфирмы могло бы включать, например, следующие требования:

Приложением будут пользоваться руководитель турфирмы, 2 менеджера по продажам, бухгалтер, кассир и 2 офисных сотрудника турфирмы – всего 7 пользователей. Предполагается, что одновременно с БД будут работать не более 3 сотрудников. Персоналу бухгалтерии для работы достаточно иметь доступ только к данным по оплате путевок.

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

Один из офисных сотрудников будет назначен системным администратором. Только он должен вести учетные записи пользователей.

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

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

1.2.2. Логическая модель

ER-диаграммы

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

В примере менеджера турфирмы имеются 5 основных объектов:

Туристы

Туры

Путевки

Сезоны

Оплаты

Отношения между этими объектами могут быть определены простыми терминами:

Каждый турист может купить одну или несколько (много) путевок.

Каждой путевке соответствует ее оплата (оплат

Объекты, атрибуты и ключи

Далее модель развивается путем определения атрибутов для каждого объекта. Атрибуты объекта – это элементы данных, относящиеся к определенному объекту, которые должны сохраняться. Анализируем составленный словарь данных, выделяем в нем объекты и их атрибуты, расширяем словарь при необходимости. Атрибуты для каждого объекта в рассматриваемом примере представлены в таблице 2.

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

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

Реляционная модель характеризуется использованием ключей и отношений. Существует отличие в контексте реляционной базы данных терминов relation (отношение) и relationship (схема данных). Отношение рассматривается как неупорядоченная, двумерная таблица с несвязанными строками.Схема данных формируется между отношениями (таблицами) через общие атрибуты, которые являютсяключами .

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

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

Для проектируемой БД расширим атрибуты объектов кодовыми полями в качестве первичных ключей и используем эти коды в отношениях БД для ссылки на объекты БД следующим образом (табл. 3).

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

Нормализация

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

Процесс нормализации состоит в пошаговом построении БД в нормальной форме (НФ).

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

Вторая нормальная форма (2НФ) создается тогда, когда удалены все частичные зависимости из отношений БД. Если в отношениях не имеется никаких составных ключей, то этот уровень нормализации легко достигается.

Третья нормальная форма (3НФ) БД требует удаления всех транзитивных зависимостей.

Четвертая нормальная форма (4НФ) создается при удалении всех многозначных зависимостей.

БД нашего примера находится в 1НФ, так как все поля таблиц БД атомарные по своему содержанию. Наша БД также находится и во 2НФ, так как мы искусственно ввели в каждую таблицу уникальные коды для каждого объекта (Код Туриста, Код Путевки и т. д.), за счет чего и добились 2НФ для каждой из таблиц БД и всей базы данных в целом. Осталось разобраться с третьей и четвертой нормальными формами.

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

Итак, какие же транзитивные и многозначные зависимости присутствуют в нашем примере БД менеджера турфирмы?

Давайте проанализируем отношение «Туристы». Рассмотрим зависимости между атрибутами «Код туриста», «Фамилия», «Имя», «Отчество» и «Паспорт» (рис. 3). Каждый турист, представленный в отношении сочетанием «Фамилия- Имя-Отчество», имеет на время поездки только один паспорт, при этом полные тезки должны иметь разные номера паспортов. Поэтому атрибуты «Фамилия- Имя-Отчество» и «Паспорт» образуют в отношении туристы составной ключ.

Составной ключ

Рис. 3. Пример транзитивной зависимости

Как видно из рисунка, атрибут «Паспорт» транзитивно зависит от ключа «Код туриста». Поэтому, чтобы исключить данную транзитивную зависимость, разобьем составной ключ отношения и само отношение на 2 по связям «один-к-одному». В первое отношение, оставим ему имя «Туристы», включаются атрибуты «Код туриста» и «Фамилия», «Имя», «Отчество». Второе отношение, назовем его «Информация о туристах», образуют атрибуты «Код туриста» и все оставшиеся атрибуты отношения «Туристы»: «Паспорт», «Телефон», «Город», «Страна», «Индекс». Эти два новых отношения уже не имеют транзитивной зависимости и находятся в 3НФ.

Многозначные зависимости в нашей упрощенной БД отсутствуют. Для примера предположим, что для каждого туриста должны храниться несколько контактных телефонов (домашний, рабочий, сотовый и пр., что весьма характерно на практике), а не один, как в примере. Получаем многозначную зависимость ключа – «Код туриста» и атрибутов «Тип телефона» и «Телефон», в этой ситуации ключ перестает быть ключом. Что делать? Проблема решается также путем разбиения схемы отношения на 2 новые схемы. Одна из них должна представлять информацию о телефонах (отношение «Телефоны»), а вторая о туристах (отношение «Туристы»), которые связываются по полю «Код туриста». «Код туриста» в отношении «Туристы» будет первичным ключом, а в отношении «Телефоны» – внешним.

1.2.3. Физическая модель

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

и индексов.

В данном пособии будут рассмотрено создание физической модели БД средствами СУБД Microsoft Access и сервера баз данных Microsoft SQL Server 2005 Express Edition.

1.3. Создание БД в СУБД Microsoft Access

1.3.1. Таблицы

Для создания таблицы в СУБД Microsoft Access используем режим конструктора (рис. 4).

Рис. 4. Выбор режима конструктора

Рис. 5. Полный список полей таблицы

В появившемся окне «Таблица1: таблица» предстоит определить названия полей, которые и станут заголовками в этой таблице. Введем следующие названия полей (рис. 5).

Процесс проектирования включает в себя следующие этапы.

Инфологическое проектирование.

Определение требований к операционной обстановке, в которой будет функционировать информационная система.

Выбор системы управления базой данных (СУБД) и других инструментальных программных средств.

Логическое проектирование БД.

Физическое проектирование БД.

1.1. Инфологическое проектирование.

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

Инфологическая модель предметной области (ПО) представляет собой описание структуры и динамики ПО, характера информационных потребностей пользователей в терминах, понятных пользователю и не зависимых от реализации БД. Это описание выражается в терминах не отдельных объектов ПО и связей между ними, а их типов, связанных с ними ограничений целостности и тех процессов, которые приводят к переходу предметной области из одного состояния в другое.

В настоящее время применяют проектирование с использованием метода "Сущность-связь"(entity–relation, ER–method), который является комбинацией предметного и прикладного методов и обладает достоинствами обоих.

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

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

Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ ).

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

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

Ассоциативная сущность (ассоциация ) – это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности. Ассоциации рассматриваются как полноправные сущности, они могут: участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности; обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь.

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

Например, муж может иметь несколько жен, книга – несколько характеристик переиздания (исправленное, дополненное, ...) и т.д.

Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.

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

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

Тип сущности характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.

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

Например, читатель библиотеки – сильная сущность, а абонемент этого читателя – слабая, которая зависит от наличия соответствующего читателя.

Слабые сущности называют подчинёнными (дочерними) , а сильные – базовыми (основными, родительскими) .

Для каждой сущности выбираются свойства (атрибуты).

Различают:

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

Составные и простые атрибуты . Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.

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

Основные и производные атрибуты . Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).

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

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

Каждая связь характеризуется именем, обязательностью , типом и степенью . Различают факультативные и обязательные связи. Если вновь порождённый объект одного типа оказывается по необходимости связанным с объектом другого типа, то между этими типами объектов существует обязательная связь (обозначается двойной линией). Иначе связь является факультативной .

По типу различают множественные связи "один к одному" (1:1), "один ко многим" (1:n) и "многие ко многим" (m:n). ER–диаграмма, содержащая различные типы связей, приведена на рис. 1. Обратите внимание, что обязательные связи на рис. 1 выделены двойной линией.

Степень связи определяется количеством сущностей, которые охвачены данной связью. Пример бинарной связи – связь между отделом и сотрудниками, которые в нём работают. Примером тернарной связи является связь типа экзамен между сущностями ДИСЦИПЛИНА , СТУДЕНТ , ПРЕПОДАВАТЕЛЬ . Из последнего примера видно, что связь также может иметь атрибуты (в данном случае это Дата проведения и Оценка ). Пример ER–диаграммы с указанием сущностей, их атрибутов и связей приведен на рис. 2.

Принимаемые проектные решения можно описать языком инфологического моделирования (ЯИМ), основанном на языке SQL, который позволяет дать удобное и полное описание любой сущности и, следовательно, всей базы данных. Например:

СОЗДАТЬ ТАБЛИЦУ Блюда *(Стержневая сущность)

ПЕРВИЧНЫЙ КЛЮЧ (БЛ)

ПОЛЯ (БЛ Целое, Блюдо Текст 60, Вид Текст 7)

ОГРАНИЧЕНИЯ (1. Значения поля Блюдо должны быть

уникальными; при нарушении вывод

сообщения "Такое блюдо уже есть".

2. Значения поля Вид должны принадлежать

набору: Закуска, Суп, Горячее, Десерт,

Напиток; при нарушении вывод сообщения

"Можно лишь Закуска, Суп, Горячее,

Десерт, Напиток");

СОЗДАТЬ ТАБЛИЦУ Состав *(Связывает Блюда и Продукты)

ПЕРВИЧНЫЙ КЛЮЧ (БЛ, ПР)

ВНЕШНИЙ КЛЮЧ (БЛ ИЗ Блюда

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Блюда КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ Блюда.БЛ КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ (ПР ИЗ Продукты

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Продукты ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Продукты.ПР КАСКАДИРУЕТСЯ)

ПОЛЯ (БЛ Целое, ПР Целое, Вес Целое)

ОГРАНИЧЕНИЯ (1. Значения полей БЛ и ПР должны принадлежать

набору значений из соответствующих полей таблиц

Блюда и Продукты; при нарушении вывод сообщения

"Такого блюда нет" или "Такого продукта нет".

2. Значение поля Вес должно лежать в пределах от 0.1 до 500 г.);

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

В ER диаграммах "Сущность-связь" сущности изображаются (рис.2) помеченными прямоугольниками , ассоциации – помеченными ромбами или шестиугольниками , атрибуты – помеченными овалами , а связи между ними – ненаправленными ребрами (линиями, соединяющими геометрические фигуры), над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.

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

(стержень)

(характеристика)

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

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

объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;

введение абстрактных понятий, удобных для решения задач системы, установление их связи с конкретными понятиями, использованными в модели;

образование классов и подклассов подобных объектов (например, класс "изделие" и подклассы типов изделий, производимых на предприятии).

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

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

ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ОПЕРАЦИОННОЙ

ОБСТАНОВКЕ.

На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, определение типа и конфигурации конкретной ЭВМ, выбор типа и версии операционной системы. Объём вычислительных ресурсов зависит от предполагаемого объёма проектируемой базы данных и от интенсивности их использования. Если БД будет работать в многопользовательском режиме, то требуется подключение её к сети и наличие соответствующей многозадачной операционной системы.

С точки зрения конечного пользователя процесс создания базы данных можно представить в виде четырех этапов:

• Анализ предметной области
• Инфологическое (концептуальное) описание данных;
• Логическое проектирование баз данных;
• Физическое проектирование баз данных.

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

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

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

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

Существует два подхода к выбору состава и структуры предметной области:

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

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

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

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

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

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

Существует три основных типа отношений:

1) «один-к-одному». Такая связь означает, что каждому значению реквизита А соответствует одно и только одно значение связанного с ним реквизита В, и наоборот. Например, каждому значению реквизита Номер паспорта соответствует единственное значение реквизита ФИО гражданина страны, и наоборот. Такую связь обозначают 1:1, графически в инфологических моделях эта связь изображается одинарными стрелками.

2)«один-ко-многим». Эта связь означает, что каждому значению реквизита А соответствует одно или несколько значений связанного с ним реквизита В, а каждому значению реквизита В соответствует одно и только одно значение реквизита А. Например, для аэропорта , из которого осуществляется множество рейсов, характерна следующая связь между описывающими этот объект реквизитами: одному значению реквизита Название аэропорта вылета соответствует несколько значений реквизита Номер рейса, а каждому значению Номер рейса соответствует только одно Название аэропорта вылета.

3)«многие-ко-многим». Такая связь означает, что каждому значению реквизита А соответствует несколько значений связанного с ним реквизита В, и наоборот. Например, турагентство может работать с несколькими туроператорами, а туроператор обычно имеет разветвленную сеть турагентов. Такую связь обозначают М: М, а графически изображают двойными стрелками.

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

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

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

На этом этапе осуществляется выбор подходящей системы управления базами данных и представление инфологической модели предметной области в форме структуры базы данных конкретной СУБД.

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

Файловая модель. Представляет собой совокупность не связанных между собой файлов из однотипных записей с линейной (одноуровневой) структурой.

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

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

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

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

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

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

Файлы прямого доступа;

Файлы последовательного доступа;

Индексные файлы.

Похожая информация.

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

Процесс проектирования включает в себя следующие этапы:

• 1. Инфологическое проектирование.
• 2. Определение требований к операционной обстановке, в которой будет функционировать информационная система.
• 3. Выбор системы управления базой данных (СУБД) и других инструментальных программных средств.
• 4. Даталогическое(логическое) проектирование БД.
• 5. Физическое проектирование БД.

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

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

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

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

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

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

Понятие “Предметная область” - базисное в теории БД и не имеет строгого определения. Оно вытекает из понятий “объект” и “предмет”. Предметная область (ПО) - часть реального мира, подлежащая изучению с целью организации управления и, в конечном итоге, автоматизации. ПО представляется множеством фрагментов , которые характеризуются множеством объектов , множеством процессов, использующих объекты, а также множеством пользователей, характеризуемых единым взглядом на предметную область.

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

Примеры.

Объект "Человек " обладает свойствами: рост, имя, дата рождения … ,

объект - "Изделие " обладает свойствами: качество, дата изготовления, внешний вид….

Между объектами существуют многочисленные связи. Например:

• · Человек покупает, продает, производит Изделие
• · Изделие создается, покупается, продается Человеком .

Предмет - модель реального объекта, в котором зафиксированы лишь выделенные для ИС свойства и связи. Совокупность отобранных предметов образует объектное ядро предметной области, а совокупность их взаимосвязей - структуру фрагмента действительности . Т.о. понятие “Предметная область” соответствует точке зрения потребителя на объектное ядро: в ней выделены только те объекты, свойства объектов и связи между объектами, которые представляют ценность для ИС и должны быть сохранены в БД.

Все действия по выявлению ядра предметной области производятся на этапе анализа ИС.

Объектное ядро системы в течение ЖЦ ИС не остается постоянным: пропадают и возникают объекты, меняются их свойства и взаимосвязи. Зафиксированные во времени цепочки этих изменений называются траекториями предметной области, а совокупность общих свойств траекторией - семантикой предметной области

Имеется целый ряд методик моделирования предметной области. Одна из наиболее популярных в настоящее время методик базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов ERD (Entity-Relationship Diagrams). В русскоязычной литературе эти диаграммы называют "объект - отношение" либо "сущность - связь".

Модель ERD была предложена в 1976 г. Питером Пин-Шэн Ченом . В дальнейшем многими авторами были разработаны свои варианты подобных моделей: нотация (notation - система обозначения, записи) Мартина, нотация IDEF1X, нотация Баркера), но все они базируются на графических диаграммах, предложенных Ченом.

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию реляционных баз данных.

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

Мы познакомимся с ER-диаграммами в нотации Баркера, как довольно легкой в понимании основных идей.

Основные понятия ER-диаграмм. Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".

Каждая сущность в модели изображается в виде прямоугольника, содержащего имя сущности:

Определение 2 . Экземпляр сущности - это конкретный представитель данной сущности.

Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".

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

Определение 3 . Атрибут сущности - это поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, КРАСКА и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д.

Здесь также существует различие между типом атрибута и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

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

Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.

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

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

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

Указывающие атрибуты используются для присвоения имени или обозначения экземплярам сущности.

Вспомогательные атрибуты используются для связи экземпляра одной сущности с экземпляром другого. Атрибуты подчиняются строго определенным правилам.

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

Например, для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления , Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

Сущность может иметь несколько различных ключей.

Ключевые атрибуты изображаются на диаграмме подчеркиванием:

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

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

Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".

Графически связь изображается линией, соединяющей две сущности:

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

Каждая связь может иметь один из следующих типов связи :

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

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской , правая (со стороны "много") - дочерней . (см. рис. графического изображения связи)

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

Каждая связь может иметь одну из двух модальностей связи :

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

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

Связь может иметь разную модальность с разных концов.

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

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

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

Слева направо: "каждый сотрудник может иметь несколько детей".

Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".

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

В первой нормальной форме ER-диаграммы устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты.

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

В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор (ключ сущности). Эти атрибуты являются основой отдельной сущности.

При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.

Получение реляционной схемы из ER-схемы:

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.

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

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.

Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.

Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

• · все подтипы в одной таблице (а)
• · для каждого подтипа - отдельная таблица (б)

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

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

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

Шаг 7. Имеется два способа работы при наличии исключающих связей:

• · общий домен (а)
• · явные внешние ключи (б)

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

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

Пример разработки простой ER-модели. При разработке ER-моделей мы должны получить следующую информацию о предметной области:

• 1. Список сущностей предметной области.
• 2. Список атрибутов сущностей.
• 3. Описание взаимосвязей между сущностями.

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

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

Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:

• · Хранить информацию о покупателях.
• · Печатать накладные на отпущенные товары.
• · Следить за наличием товаров на складе.

Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):

• · Покупатель
• · Накладная - явный кандидат на сущность.
• · Товар - явный кандидат на сущность
• · (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
• · (?)Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:

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

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

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

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

инфологический атрибут информационный отображение

Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:

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

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

• · Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.
• · Наименование покупателя
• · Адрес - явная характеристика покупателя.
• · Банковские реквизиты - явная характеристика покупателя.
• · Наименование товара
• · (?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
• · Единица измерения - явная характеристика товара.
• · Номер накладной - явная уникальная характеристика накладной.
• · Дата накладной - явная характеристика накладной.
• · (?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.
• · (?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".
• · (?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
• · Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.
• · Наименование склада - явная характеристика склада.

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

С возникающим понятием "Список товаров в накладной" все довольно ясно.

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

Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами

- "каждая накладная обязана иметь несколько записей из списка товаров в накладной",

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

Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

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

Теперь можно внести все это в диаграмму:

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

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

Полученные таблицы находятся в 3НФ.

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

Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей.

Более сложные элементы ER-модели. Мы остановились только на самых основных и наиболее очевидных понятиях ER-модели данных. К числу более сложных элементов модели относятся следующие:

· Подтипы и супертипы сущностей. Как в языках программирования с развитыми типовыми системами (например, в языках объектно-ориентированного программирования), вводится возможность наследования типа сущности, исходя из одного или нескольких супертипов.

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

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

Пример: Супертип ЛЕТАТЕЛЬНЫЙ АППАРАТ

Как полагается это читать? От супертипа: ЛЕТАТЕЛЬНЫЙ АППАРАТ, который должен быть АЭРОПЛАНОМ, ВЕРТОЛЕТОМ, ПТИЦЕЛЕТОМ или ДРУГИМ ЛЕТАТЕЛЬНЫМ АППАРАТОМ. От подтипа: ВЕРТОЛЕТ, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА. От подтипа, который является одновременно супертипа: АЭРОПЛАН, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА и должен быть ПЛАНЕРОМ или МОТОРНЫМ САМОЛЕТОМ.

Иногда удобно иметь два или более разных разбиения сущности на подтипы. Например, сущность ЧЕЛОВЕК может быть разбита на подтипы по профессиональному признаку (ПРОГРАММИСТ, ДОЯРКА и т.д.), а может - по половому признаку (МУЖЧИНА, ЖЕНЩИНА).

• · Связи "many-to-many". Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности (например, все члены кооператива сообща владеют имуществом кооператива). Для этого вводится разновидность связи "многие-со-многими".
• · Уточняемые степени связи. Иногда бывает полезно определить возможное количество экземпляров сущности, участвующих в данной связи (например, служащему разрешается участвовать не более, чем в трех проектах одновременно). Для выражения этого семантического ограничения разрешается указывать на конце связи ее максимальную или обязательную степень.
• · Каскадные удаления экземпляров сущностей. Некоторые связи бывают настолько сильными (конечно, в случае связи "один-ко-многим"), что при удалении опорного экземпляра сущности (соответствующего концу связи "один") нужно удалить и все экземпляры сущности, соответствующие концу связи "многие". Соответствующее требование "каскадного удаления" можно сформулировать при определении сущности.
• · Домены . Как и в случае реляционной модели данных бывает полезна возможность определения потенциально допустимого множества значений атрибута сущности (домена).

Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).

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

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