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

- Заказчик, лицо желающее получить строительные услуги;

- Подрядчик, лицо предоставляющее строительные услуги;

- Поставщик материалов, лицо, обязующееся поставлять материалы на строительство.

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

- Смета, документ, определяющий стоимость работ по договору.

Накопителями данных являются:

- информация о заказчиках;

- информация о подрядчиках;

- информация о поставщиках материалов;

- информация о договорах;

- информация о проектно-сметной документации

Информационная система разбита на четыре логические подсистемы:

- система формирования и редактирования исходных данных;

- система запросов;

- система формирование отчетов;

- система анализа данных.

Рис. 3. Концептуальная модель

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

1,4,5 – формирование справочника заказчики;

4,2,6 – формирование справочника поставщики;

3,4,7 – формирование справочника подрядчики;

4,11,9 – формирование данных по договору с заказчиками

Рис.4. Схема потоков данных

12,4,9 – формирование данных по договору с подрядчиками

4,13,9 – формирование данных по договору с поставщиками

4,10 – формирование справочника ответственное лицо

4,11,12,9 – формирование учетных данных по договору с заказчиками

4,12,14,9 - формирование учетных данных по договору с подрядчиками

4,14,13,9 - формирование учетных данных по договору с поставщиками

17,15 – формирование запрос а по менеджерам

16,18,15 -

18,19,20,15 – формирование запроса по суммам договоров подрядчиков

21,19,18,15 – формирование запроса по заказчикам, договорам, сметам;

22,23,24,15 – формирование отчета по заказчикам, договорам, сметем;

25,26 – аналитический отчет

27,28 - отчет по подрядчикам

29,27 - отчет по поставщикам материалов

26,27 - отчет по отелу договоров

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

Рис.5. Инфологическая модель данных

Датологическая модель (рис.6) строится на основе разработанной инфологической модели и наиболее приемлемой для дальнейшей разработки является реляционная модель данных, где вся информация хранится в виде связанных таблиц, что дает возможность более эффективно хранить информацию, сохраняя целостность данных. Между таблицами устанавливаются отношения «один-ко-многим». Это самый распространенный вид отношений в реляционной базе данных.