Создание концептуальной модели базы данных

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

1. Обеспечение хранения в БД всей необходимой информации.

2. Обеспечение возможности получения данных по всем необходимым запросам.

3. Сокращение избыточности и дублирования данных.

4. Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

Концептуальное (инфологическое) проектирование— построение семантической (смысловой) модели предметной области. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «модель базы данных», «модель предметной области», «концептуальная модель», «концептуальная модель базы данных», «концептуальная модель предметной области» и «инфологическая модель» являются синонимами.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

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

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

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

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

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

Модель "сущность–связь"

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

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

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

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

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

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

В рассматриваемой предметной области БАНК можно выделить три связи.

1. МЕНЕДЖЕР – УПРАВЛЯЕТ – ФИЛИАЛ

2. ФИЛИАЛ – ОБРАБАТЫВАЕТ – СЧЕТ

3. КЛИЕНТ – ИМЕЕТ – СЧЕТ

На ER-диаграмме связь изображается ромбом. Например,

Важной характеристикой связи является тип связи (кардинальность). Рассмотрим типы связей 1–3.

Так как менеджер управляет только одним филиалом, то каждый экземпляр сущности МЕНЕДЖЕР может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 1имеет тип "один-к-одному" (1:1). На рисунке 3.3 представлена ER-диаграмма для связи типа 1:1.

Рисунок 3.3 – ER-диаграмма связи 1:1

Так как филиал обрабатывает несколько счетов, а счет обрабатывается только одним филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с одним экземпляром сущности СЧЕТ, а каждый экземпляр сущности СЧЕТ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 2 имеет тип "один-ко-многим" (1:М). На рисунке 3.4 представлена ER-диаграмма для связи типа 1:М.

Рисунок 3.4 – ER-диаграмма связи 1:М

Так как счет может совместно использоваться несколькими клиентами и клиент может иметь несколько счетов, то каждый экземпляр сущности СЧЕТ может быть связан с несколькими экземплярами сущности КЛИЕНТ и каждый экземпляр сущности КЛИЕНТ может быть связан с несколькими экземплярами сущности СЧЕТ. В этом случае связь 3имеет тип "многие-ко-многим" (М:N). На рисунке 3.5 представлена ER-диаграмма для связи типа М:N.

Рисунок 3.5 – ER-диаграмма связи M:N

Рассмотрим понятие класс принадлежности сущности.

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

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

В качестве примера на рисунке 3.6 изображены возможные ER-диаграммы для связи М:N c учетом класса принадлежности сущности.

Рисунок 3.6 – ER-диаграммы связи М:N с учетом

класса принадлежности сущности

На ER-диаграмме 1 класс принадлежности обеих сущностей необязательный.

На ER-диаграмме 2 класс принадлежности сущности КЛИЕНТ обязательный, а сущности СЧЕТ необязательный.

На ER-диаграмме 3 класс принадлежности сущности КЛИЕНТ необязательный, а сущности СЧЕТ обязательный.

На ER-диаграмме 4класс принадлежности обеих сущностей обязательный.

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

Каждая из четырех сущностей приведенной ER-модели может быть описана своим набором атрибутов (рис. 3.8).

ER-модель в совокупности с наборами атрибутов сущностей может служить примером концептуальной модели предметной области или концептуальной схемы базы данных.

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

Рисунок 3.7 – Пример ER–модели предметной области БАНК

МЕНЕДЖЕР ФИЛИАЛ
Номер менеджера (НМ) Номер филиала (НФ)
Стаж работы (СТАЖ) Адрес филиала (АДР_Ф)
Специальность (СПЕЦ)
КЛИЕНТ
СЧЕТ Номер клиента (НК)
Номер счета (НС) Ф.И.О. клиента (ФИО_К)
Тип счета (ТИП) Социальное положение (СОЦ)
Остаток на счете (ОСТ) Адрес клиента (АДР_К)

Рисунок 3.8 – Наборы атрибутов сущностей предметной области Банк

Примечание. Ключевые атрибуты выделены жирным шрифтом.

http://www.site-do.ru/db/db4.php – пример концептуальной модели

http://www.site-do.ru/db/db5.php – преобразование в реляционную (до процесса нормализации)

| следующая лекция ==>
Метод вспомогательных секущих плоскостей | Лекция 4. Нормализация

Дата добавления: 2014-01-03 ; Просмотров: 8239 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Дата публикации: 23.06.2014

Библиографическая ссылка:
Столяров А.И. Построение концептуальной схемы баз данных // Портал научно-практических публикаций [Электронный ресурс]. URL: http://portalnp.ru/2014/06/2064 (дата обращения: 26.11.2019)

Столяров Александр, студент 2 курса, направление подготовки прикладная информатика

ФГБОУ ВПО Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «МГТУ имени Носова»

Аннотация

Читайте также:  Бак заполненный водой до высоты 1 м

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

Develop a conceptual database model

Stolyarov Alexandr, 2nd year student, specialty Applied Informatics,

Magnitogorsk State Technical University of a name Nosov

Annotation

The article defines database concepts and conceptual model. The basic components related to the conceptual model, the stages of its creation, as well as its meaning and application.

§1. База Данных и её проектирование

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

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

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

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

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

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

Можно выделить несколько этапов проектирования БД:

1. Концептуальное проектирование – это сбор, анализ, редактирование требований к данным. Осуществляют следующие мероприятия:

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

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

c. интеграция атак же моделирование всех представлений.

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

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

3. Физическое проектирование – это определение особенностей хранения данных и методов доступа к ним.

§2. Концептуальная модель и её основные определения.

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

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

Есть две понятийные области в концептуальной модели. Каждая из них построена по принципу иерархии. 1-я область – это дерево типов данных, 2-я – дерево данных.

Дадим основные определения:

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

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

События – совокупность реакций объекта на изменения внешней среды, описанных в базе данных.

Тип – совокупность свойств и событий объекта, описанных как единая группа.

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

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

1. включение в дереве данных,

2. вставка из другого типа значения свойства.

3. ссылка на экземпляр типа в дереве данных. Включение позволяет строить дерево данных.

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

§ 3. Создание концептуальной модели.

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

Ниже рассматривается последовательность шагов при концептуальном проектировании:

1. Выделение сущностей.

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

– примеров и аналогий при описании объектов;

Каждая сущность должна обладать следующими свойствами:

– должна иметь уникальное имя;

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

– обладать одним или несколькими атрибутами, которые делают уникальной каждую строку таблицы;

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

2. Определение атрибутов.

Выявленные атрибуты могут быть следующих видов:

– простой (или атомарный, неделимый) – состоящий из одного компонента с независимым существованием;

– составной (псевдоатомарный) – состоящий из нескольких компонентов;

– однозначный – содержащий только одно значение для одного экземпляра;

– многозначный – содержащий несколько значений;

– производный (или вычисляемый) – значение атрибута может быть определено по значениям других атрибутов;

– ключевой – служащий для уникальной идентификации экземпляра сущности;

– неключевой (или описательный) – не входящий в первичный ключ;

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

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

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

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

– суперключ (superkey) – это атрибут или множество атрибутов, идентифицирующий экземпляр сущности;

– потенциальный ключ (potential key) – это суперключ, не содержащий подмножества, являющегося суперключом данной сущности;

– первичный ключ (primary key) – это потенциальный ключ, выбранный для идентификации экземпляров;

– альтернативные ключи (alternative key) – это потенциальные ключи, не выбранные в качестве первичного ключа;

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

3. Определение связей.

Наиболее типичными видами связей между сущностями являются:

– связи типа «часть–целое»;

– функциональные связи, определяемые глаголами.

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

Читайте также:  Системные требования игры скайрим

4. Определение суперклассов и подклассов.

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

Суперкласс – сущность, включающая в себя подклассы.

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

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

Иерархии категорий можно разделить на два типа: неполные и полные.

Полная категория: одному экземпляру родового предка обязательно соответствует экземпляр в каком-либо потомке.

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

§4. Значение

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

Концептуальная модель имеет множество преимуществ:

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

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

Словарь пользователя помогает достичь целостности в терминологии.

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

Источники

  1. «Киберфорум»URL-Доступ: http://citforum.ru/cfin/prcorpsys/infsistpr_09.shtml
  2. Создание схемы данных для сервера Oracle с помощью AllFusion Data Modeler Махмутова М.В., Махмутов Г.Р. Сборник научных трудов Sworld. 2010. Т. 3. № 2. С. 58a-61.
  3. Концептуальные модели данных. Модель «сущность-связь». Сущности, атрибуты, связи. Сущности-связи и мощности связей. Примеры.[Электронный ресурс] E-educ.ru – заботясь об образовании; URL-Доступ: http://e-educ.ru/bd12.html
  4. Разработка информационной модели URL-Доступ: http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M4/L7.htm
  5. Концепции и терминология для концептуальной схемы и информационной базы [Текст]: ГОСТ 34.320 96; Введ. 03.10.1996

Количество просмотров публикации: –

Связь с автором публикации (комментарии/рецензии к публикации)

Оставить комментарий

Вы должны авторизоваться, чтобы оставить комментарий.

Инструменты пользователя

Инструменты сайта

Содержание

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

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

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

Структурирование – это набор соглашений о способах представления данных.

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

Иерархическая структура базы данных

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

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

Сетевая структура базы данных

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

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

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

Объектно-ориентированные и гибридные базы данных

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

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

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

Реляционные базы данных, как мы уже знаем, состоят из таблиц. Каждая таблица состоит из столбцов (их называют полями или атрибутами) и строк (их называют записями или кортежами). Таблицы в реляционных базах данных обладают рядом свойств. Основными являются следующие:

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

Теоретически (на бумаге) мы можем все это расположить в одной таблице, например, так:

Но это противоречит свойству атомарности (одно значение в одной ячейке), а в столбцах Темы и Сообщения у нас предполагается неограниченное количество значений. Значит, нашу таблицу надо разбить на три: Пользователи, Темы и Сообщения. Наша таблица Пользователи удовлетворяет всем условиям. А вот таблицы Темы и Сообщения – нет. Ведь в таблице не может быть двух одинаковых строк, а где гарантия, что один пользователь не оставит два одинаковых сообщения, например:

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

Первичный ключ (сокращенно РК – primary key) – столбец, значения которого во всех строках различны. Первичные ключи могут быть логическими (естественными) и суррогатными (искусственными). Так, для нашей таблицы Пользователи первичным ключом может стать столбец e-mail (ведь теоретически не может быть двух пользователей с одинаковым e-mail). На практике лучше использовать суррогатные ключи, т.к. их применение позволяет абстрагировать ключи от реальных данных. Кроме того, первичные ключи менять нельзя, а что если у пользователя сменится e-mail?

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

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

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

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

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

Читайте также:  Завис документ ворд что делать

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

Но как поставщик поставляет товары? Он делает поставку, которая подтверждается документом. Аналогично и покупатель делает покупку, которая также может подтверждаться документом. Таким образом, поставка и покупка могут рассматриваться, как самостоятельные объекты: Таким образом, у нас появилось еще два объекта – журнал покупок и журнал поставок, со связями «один ко многим» (один журнал поставок может включать несколько поставок, но каждая поставка может входить только в один журнал, аналогично и для остальных).

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

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

Преобразование концептуальной модели в реляционную состоит в следующем:

Итак, нам надо построить набор таблиц. Сделать это несложно, т.к. таблицы – это наши объекты, а поля таблиц – атрибуты объектов. Набор предварительных таблиц, исходя из нашей концептуальной модели, выглядит так: Таким образом, у нас определены таблицы, поля, первичные ключи (РК) и связи (FK). Обратите внимание, в таблицах Журнал поставок и Журнал покупок первичные ключи – составные, т.е. состоят из двух полей. Теоретически бывают таблицы, в которых все поля являются одним составным ключом.

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

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

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

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

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

Для реляционных баз данных необходимо, чтобы ее таблицы находились в 1НФ. Нормальные формы более высоких уровней могут использоваться разработчиками по своему усмотрению. Однако грамотный специалист стремится к тому, чтобы довести уровень нормализации базы данных хотя бы до 3НФ, тем самым исключив избыточность данных и аномалии обновления. Надо сказать, что НФБК, 4НФ и 5НФ используются крайне редко. Поэтому и мы рассмотрим только первые три.

Первая нормальная форма

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

Но что если наши поставщики находятся в разных городах? Тогда, посылая машину за товарами в определенный город, мы должны быть уверенны, что она заберет товары у всех поставщиков, находящихся в этом городе. Т.е. нам могут понадобиться сведения о поставщикам, находящихся в определенном городе. В этом случае, значения в поле Адрес уже не являются атомарными (т.к. мы используем часть адреса), и для приведения таблицы к 1НФ нам надо выделить еще одно поле – Город:

Таким образом надо проанализировать все таблицы нашей базы данных. Так, в таблице Покупатель есть поле ФИО. Если мы собираемся, например, поздравлять наших покупателей с именинами (которые, как известно, завися от имени), то это поле пришлось бы разбить на три: Фамилию, Имя и Отчество. Наш магазин этого делать не собирается, поэтому поле ФИО можно считать атомарным, а таблицу – приведенной к 1НФ.

Вторая нормальная форма

Эта форма применяется к таблицам с составными ключами. Таблица, у которой первичный ключ включает только одно поле, всегда находится во 2НФ

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

В нашей базе данных две таблицы имеют составной ключ – Журнал покупок и Журнал поставок. Значение поля Количество зависит, как от Поставки (Покупки), так и от Товара. Значит, наши таблицы находятся во 2НФ.

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

Посмотрим теперь на таблицу Журнал поставок: поле Количество зависит от Наименования товара и от Даты поставки, но не зависит от того, кто поставил товар (поле Поставщика). Т.е. таблица не находится во 2НФ. Если бы на этапе концептуального моделирования нашей базы данных, мы не выделили объекты Поставка и Покупка, нам бы пришлось это делать сейчас. Но мы их выделили, поэтому все наши таблицы находятся во 2НФ.

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

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

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

Посмотрим на нашу таблицу Товар. В ней есть поле Цена, но цены, как известно, имеют свойство меняться. Если мы будем их менять прямо здесь, то будет пропадать вся информация о предыдущих ценах. Чтобы не терять эту информацию, надо добавить поле Дата (когда изменилась цена). Тогда наша таблица будет выглядеть так:

Даже не прибегая к 3НФ видно, что такая таблица будет содержать избыточную информацию. Но посмотрим на ее поля: поля Наименование и Дата зависят от /> Все остальные таблицы нашей базы данных находятся в 3НФ. Кстати, в таблице Товар можно было и не вводить поле id товара, а сделать первичным ключом поле Наименование, но как уже говорилось в третьем уроке суррогатные ключи все-таки предпочтительнее.

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