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

Предметная область - часть реального мира, подлежащая изучению с целью организации управления и автоматизации [1 - с.8].

В ходе анализа предметной области необходимо:

· уяснить и указать назначение базы данных;

· определить и выделить первоначальный набор сущностей и атрибутов предметной области.

Рассмотрим пример проектирования базы данных предметной области "Сеть ресторанов".

Назначение и предметная область

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

· прием заказов на основе составленного меню, обслуживание клиентов;

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

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

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

1) Сущности.

Сущности - любой конкретный или абстрактный объект в рассматриваемой предметной области. Следует различать понятия "тип сущности" и "экземпляр сущности". Тип сущности - это набор однородных личностей, предметов, выступающих как единое целое. А экземпляр сущности - конкретная вещь в наборе.

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

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

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

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

Теперь о внешних ключах:

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

Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

В реляционной базе данных сущности представлены в виде таблиц.

В рассматриваемой информационной системе сущностями являются: Список заведений, Раздел, Сотрудники, Меню, Заказы.

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

2) Атрибуты.

Атрибут - свойство сущности в данной предметной области. Названия атрибутов одной сущности должны быть различны.

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

Атрибуты сущности Список заведений:

Атрибуты сущности Разделы:

Атрибуты сущности Сотрудники:

Атрибуты сущности Меню:

Атрибуты сущности Заказы:

3) Связи.

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

Различают следующие виды связей:

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

· Взаимосвязь "один-ко-многим" свидетельствует о том, что одной записи в одном объекте может соответствовать несколько записей в другом объекте и обозначается с помощью одинарной стрелки в одном направлении и двойной стрелки в другом направлении.

· Взаимосвязь "многие-ко-многим" свидетельствует о том, что одной записи в одном объекте может соответствовать несколько записей в другом объекте и наоборот, обозначается такая связь с помощью двойной стрелки в одном направлении и двойной стрелки в другом направлении.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Тип отношения в создаваемой связи зависит от способа определения связываемых полей:

1) отношение "один-ко-многим" создается в том случае, когда только одно из полей является полем первичного ключа или уникального индекса

2) отношение "один-к-одному" создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.

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

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

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

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

Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.

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

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

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

Логическая модель отражает структуру базы данных в виде блок-схемы связи сущностей. Такая блок-схема называется ER-диаграммой (от. англ. entity - сущность, relationship - отношение).

Модель "сущность-связь" была предложена Питером Ченом (Peter Chen) в 1976 году, в качестве унифицированного способа описания предметной области. Как самостоятельная модель данных она развития не получила, но стала основой для создания инфологических моделей БД [1 - c.32].

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

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

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

Пусть R - реляционное отношение, а X и Y - некоторые подмножества атрибутов этого отношения. Y функционально зависимо от X тогда и только тогда, когда для каждого значения множества X существует только одно значение множества Y. Иначе говоря, если два кортежа отношения совпадают по значению X, то они обязательно будут совпадать и по значению Y. Записывается функциональная зависимость (ФЗ) как X>Y, читается как "X функционально определяет Y". Если существует ФЗ X>Y, то X называют детерминантом, а Y - зависимой частью.

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

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

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

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

При описании 2НФ и 3НФ везде, кроме случаев, где это указано явно, предполагается, что реляционные отношения имеют только один потенциальный ключ.

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

Процесс разбиения отношения R{A,B,C} на два отношения R1{A,B}, R2{A,C} называется проецированием, а отношения R1 и R2 - проекциями. Здесь А, В и С - это некоторые непересекающиеся подмножества атрибутов исходного отношения, объединение которых даст все множество атрибутов. Если была произведена декомпозиция без потерь, то соединение проекций R1 и R2 должно дать исходное отношение R.

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

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

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

Поскольку во всех отношениях не имеют места транзитивные зависимости, то они находятся в 3 нормальной форме. Например, отношение Меню находится в 3 нормальной форме т.к. все его неключевые поля: Название, Цена, Код заведения, Код раздела полно зависят от ключевого атрибута Код блюда. Аналогично для всех других отношений.

Таким образом, отношения находятся в 3 нормальной форме.

1.2 Даталогическое моделирование