Первичные ключи таблиц

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

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

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

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

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

Преобразование составных атрибутов

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

Преобразование сущностей в атрибуты

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

Преобразование множественных атрибутов

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

Преобразование атрибутов супертипов и подтипов

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

5.3.3Создание реляционной схемы данных

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

6Разработка программного приложения

6.1.Реализация базы данных в СУБД Access

Процесс реализации базы данных в СУБД Access включает в себя следующие этапы:

1. Создание таблиц базы данных:

• определение имен полей;

• определение ключевого поля;

• определение свойств полей;

• определение свойств таблиц;

• создание полей подстановок.

2. Создание схемы данных:

• установление связей;

• определение мощностей связей.

3. Заполнение таблиц данными.

Для всех таблиц модели необходимо определить характеристики и свойства их полей. К обязательным характеристикам относятся:

• имя поля;

• тип данных;

• размер поля;

• является ли поле обязательным (т.е. может ли оно иметь значение NULL);

• является ли поле индексированным и возможны ли совпадения значений поля.

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

• формат поля;

• маска ввода;

• условие на значение;

• значение, принимаемое для поля по умолчанию (если таковое имеется);

• подпись для поля (если она не будет совпадать с именем поля).

Подраздел "Реализация базы данных в СУБД Access " пояснительной записки к курсовой работе должен содержать:

• схему данных;

• описание свойств полей;

• описание свойств таблиц;

• таблицы с введенными в них данными

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

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

• общий вид Главной кнопочной формы и остальных элементов интерфейса, а также описание их назначения и порядка создания.