9.Основы проектирования бд. Этапы проектирования.

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

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

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

Этот этап включает в себя:

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

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

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

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

2. Проектирование логической модели данных

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

3. Проектирование физической модели БД.

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

4. Оценка физической модели БД.

5. Реализация БД.

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

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

Введение нормализации таблиц обеспечивает минимальный объем физической БД и ее максимальное быстродействие. Нормализация модели выполняется в несколько этапов.

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

Этапы нормализации:

• Отношение находится в первой нормальной форме, если его атрибуты являются простыми.

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

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

Аномалии схем отношений – это наиболее часто встречающиеся недостатки схем отношений. Например, рассмотрим схему отношения:

Изготовители = (наэв_изгот, адрес_изгот, изделие, колич_за_год, цена)

Недостатки схемы:

1. Избыточность.

Адрес изготовителя повторяется для каждого изготовляемого изделия.

2. Потенциальная противоречивость (аномалии обновления).

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

3.Аномалии включения.

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

4. Аномалии удаления.

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

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

Для построения оптимальной (нормализованной) модели:

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

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

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

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

Рекомендуется использовать цифровой код, если:

1. Естественный атрибут таблицы не обладает свойствами уникальности. Например, наличие однофамильцев.

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

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

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

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