Строительно-монтажные работы – Сметы. Тип связи 1:М, т. к. каждый вид работ может выполняться на разных объектах. На каждый тип работы составляется смета.

Сметы – Реестры. Тип связи 1:М, т. к. 1 тип сметы может вноситься в разные реестры.

Акты — Реестры. Тип связи 1:М, т. к. 1 номер акта может вноситься в разные реестры.

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

• нужно использовать потенциальный ключ с минимальным набором атрибутов;

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

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

• значения ключа должны иметь минимальную длину;

• с выбранным ключом пользователю будет проще работать.

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

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

2.2 Разработка логической модели базы данных

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

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

• связи типа «многие – ко - многим»;

• рекурсивные связи;

• связи с атрибутами;

• множественные атрибуты;

• избыточные связи.

Разрыв связей «многое-ко-многому» осуществляется путем введения некоторой дополнительной сущности, которая конкретизирует понятия и изменяет связь «многое-ко-многому» на связь типа 1:М или М:1. Обязательными реквизитами новой сущности должны быть ключи сущностей, имеющих связь типа М:N.

2.3 Разработка модели сущность-связь

Основными понятиями модели «сущность- связь» являются:

• сущность;

• связь;

• атрибуты.

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

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

В сущности «Строительно-монтажные работы» ключом выбирается реквизит «Код работ», который по ограничению задачи уникален для всей организации и удобен для использования.

«Сметы»: ключевой реквизит — «Код сметы», так как однозначно определяет уникальность записи БД, он компактен и удобен для обработки.

«Акты» ключом будет являться «Код акта».

3 Проектирование базы данных

3.1 Преобразование модели «сущность-связь» в реляционную модель данных

Преобразование модели «сущность-связь» в реляционную модель данных осуществляется путем последовательного выполнения ряда шагов:

• каждой сущности ставится в соответствие отношение реляционной модели данных;

• каждый атрибут сущности становится атрибутом соответствующего отношения;

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

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

Таблица 3.1 - Атрибуты отношения «Объекты»

Атрибут	Тип данных	Обязательность	Ключевое поле
«Код объекта »	Счетчик	обязательный	да
«Наименование объекта »	Текстовый	обязательный	нет

Таблица 3.2 - Атрибуты отношения «Строительно-монтажные работы»

Атрибут Тип данных Обязательность Ключевое поле	«Код работ» Счетчик обязательный да	«Наименование работ» Текстовый обязательный нет	Таблица 3.3 - Атрибуты отношения «Акты «
Атрибут	Тип данных	Обязательность	Ключевое поле
«Код акта»	Счетчик	обязательный	да
«№ акта»	Числовой	обязательный	нет
«Месяц»	Текстовый	обязательный	нет
«Год»	Текстовый	обязательный	нет
«Код объекта»	Числовой	обязательный	нет

Таблица 3.4 - Атрибуты отношения “ Сметы ”

Атрибут	Тип данных	Обязательность	Ключевое поле
«Код сметы»	Счетчик	обязательный	да
«№ сметы»	Числовой	обязательный	нет
«Код строительно-монтажных работ»	Числовой	обязательный	нет

Таблица 3.5 - Атрибуты отношения “ Реестры ”

Атрибут	Тип данных	Обязательность	Ключевое поле
«Номер реестра»	Счетчик	обязательный	нет
«Код акта»	Числовой	обязательный	нет
«Код сметы»	Числовой	обязательный	нет
«Базисная сметная стоимость»	Денежный	обязательный	нет
«Договорная цена»	Денежный	обязательный	нет
«В т.ч.материалы заказчика»	Денежный	обязательный	нет
«К оплате»	Денежный	обязательный	нет
«Материалы подрядчика без ГСМ»	Денежный	обязательный	нет
«Оборудование»	Денежный	обязательный	нет
«М/лом»	Текстовый	необязательный	нет

Таблица 3.6 - Атрибуты отношения “Наименование работ”

Атрибут	Тип данных	Обязательность	Ключевое поле
«Код акта»	Числовой	обязательный	нет
«Шифр»	Текстовый	обязательный	нет
«Наименование работ»	Текстовый	обязательный	нет

3.2 Физическое проектирование таблиц БД

В качестве СУБД предполагается использовать СУБД Microsoft Access, основным преимуществом которой является возможность создания и эксплуатации достаточно мощных баз данных без необходимости что-либо программировать. Еще одно дополнительное достоинство Access –интегрированность этой программы с Excel, Word и другими программами пакета MS Office.

На клиентских машинах используется операционная система Microsoft Windows XP, а также офисные средства этой же фирмы (Microsoft Office 2003).

Физическое проектирование заключается в создании БД в среде конкретной СУБД.

Разработка производится последовательно:

• создаются таблицы БД;

• вводятся необходимые ограничения;

• определяются ключевые поля;

• формируются связи между таблицами;

• обеспечиваются условия целостности данных.

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

Рисунок 3.1 – Таблица «Объекты»

Рисунок 3.2 – Таблица «Строительно-монтажные работы»

Рисунок 3.3 – Таблица «Акты»

Рисунок 3.4 – Таблица «Сметы»

Рисунок 3.5 – Таблица «Реестры»

Рисунок 3.6 – Таблица «Наименование работ»

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

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

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

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