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

 

 

 

 

 

Рисунок 5- Наборы атрибутов сущностей предметной области ГАИ

 

 

1.4 Проектирование логической структуры базы данных методом нормальных форм

 

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

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

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

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

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

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

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

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

6. Если связь типа М:N, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

На ER-диаграмме связи 1:М, представленной на рисунок 4, класс принадлежности сущностей «водитель», «автомобиль» является обязательным. Тогда согласно правилу 4 должны быть сгенерированы две таблицы следующей структуры:

                                                     Водитель

НВУ

ФИО

АДР

ТЕЛ

Водитель – Автомобиль

Н_АВТ

МАР

МОД

ЦВ

ГОД_В

ДАТ_Р

НВУ

Связь между указанными таблицами будет иметь вид

Н_АВТ

МАР

МОД

ЦВ

ГОД_В

ДАТ_Р

НВУ

НВУ

ФИО

АДР

ТЕЛ

 

На ER-диаграмме связи 1:М, представленной на рисунок 4, класс принадлежности сущности  на стороне М «взыскание»  является обязательным. Тогда согласно правилу 4 должны быть сгенерированы две таблицы следующей структуры:

                                                       Водитель

НВУ

ФИО

АДР

ТЕЛ

Водитель – Взыскание

КН

ДАТ_Н

НВУ

Р_Н

РАЗМ_ШТР

ОПЛ_ШТР

СР_Л

Б_В

Л_НОМ

Связь между указанными таблицами будет иметь вид

 

НВУ

ФИО

АДР

ТЕЛ

КН

ДАТ_Н

РАЗМ_ШТР

Р_Н

НВУ

ОПЛ_ШТР

СР_Л

Б_В

Л_НОМ

Так как в таблице «Водитель – Взыскание» уже существует атрибут НВУ, то его повторно не добавляют.

На ER-диаграмме связи 1:М, представленной на рисунок 4, класс принадлежности сущности  на стороне М «взыскание»  является обязательным. Тогда согласно правилу 4 должны быть сгенерированы две таблицы следующей структуры:

                                                   Нарушение

КН

ВИД_Н

ШТР

ПРЕД

СРОК_Л

                                        Нарушение - Взыскание

КН

ДАТ_Н

НВУ

Р_Н

РАЗМ_ШТР

ОПЛ_ШТР

СР_Л

Б_В

Л_НОМ

Связь между указанными таблицами будет иметь вид

КН

ВИД_Н

ШТР

ПРЕД

СРОК_Л

ОПЛ_ШТР

ДАТ_Н

НВУ

Р_Н

РАЗМ_ШТР

КН

СР_Л

Б_В

Л_НОМ

Так как в таблице «Нарушение - Взыскание» уже существует атрибут КН, то его повторно не добавляют.

Анализ состава атрибутов полученных таблиц A, B, C, D, E, F показывает, что таблица C является составной частью таблицы А, таблица F - составной частью таблицы D. Поэтому таблицы C, F можно исключить из рассмотрения. Оставшиеся таблицы A, B, D, E можно связать посредством связи первичных и вторичных ключей. В результате получим реляционную модель для ER-модели предметной области ГАИ.

 

 

 

 

 

 

 

 

НВУ

ФИО

АДР

ТЕЛ

 

Н_АВТ

МАР

МОД

ЦВ

ГОД_В

ДАТ_Р

НВУ

КН

ДАТ_Н

НВУ

Р_Н

РАЗМ_ШТР

ОПЛ_ШТР

СР_Л

Б_В

Л_НОМ

КН

ВИД_Н

ШТР

ПРЕД

СРОК_Л

 

Рисунок 6 - Реляционная модель предметной области ГАИ

Реляционная база данных считается эффективной, если она обладает приведенными ниже характеристиками:

1. Минимизация избыточных данных;
2. Минимальное использование отсутствующих значений (Null-значений);
3. Предотвращение потери информации.

В базе данных присутствует избыточность, если одни и те же данные находятся в нескольких местах. Минимизировать избыточность данных позволяет процесс, называемый нормализацией таблиц. Методику нормализации таблиц разработал американский ученый А.Ф.Кодд в 1970 году. Ее суть сводится к приведению таблиц к той или иной нормальной форме. Были выделены три нормальные формы – 1НФ, 2НФ, 3НФ. Позже стали выделять нормальную форму Бойса-Кодда (НФБК), а затем 4НФ и 5НФ. Каждая последующая нормальная форма вводит определенные ограничения на хранимые в базе данные.

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

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

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

Определение 3НФ: таблица находится в 3НФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных  зависимостей. Транзитивной  зависимостью называется функциональная зависимость между неключевыми полями. Все созданные таблицы находятся в 3НФ. Таким образом, реляционная модель предметной области ГАИ после нормализации таблиц остается прежней (рис. 6).

 

Глава 2. Технический проект.

2.1 Выбор состава технических и программных средств

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

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

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

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

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

 

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

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