РефератРеферат Проектирование базы данных 3
Работа добавлена на сайт bukvasha.net: 2015-10-28
Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
1. ПРОЕКТИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ДАННЫХ
1.1. ФУНКЦИОНАЛЬНАЯ СХЕМА ДАННЫХ
В состав базы данных «Предприятие» входят следующие объекты данных: 1) объект «Организации»; 2) объект «Виды деятельности»; 3) объект «Товары и услуги»; 4) объект «Запросы». Для этой базы данных характерна иерархичность объектов данных. Главным объектом является объект «Организации». Объекты «Виды деятельности» и «Товары и услуги» являются справочниками, используемыми для заполнения соответствующих элементов данных в объекте «Организации». Объект «Запросы» тоже является, если так можно выразиться, дополнением к объекту «Организации». На основании этого можно выделить два уровня иерархичности – на первом уровне будет объект «Организации», на втором уровне будут остальные объекты. Объект данных «Организации» предназначен для хранения данных о предприятии. Ввод данных в этот объект производится на основании предоставленной каждым конкретным предприятием информации. Данные, хранящиеся в объекте «Организации», используются при составлении всех выходных документов, в которых указываются названия и адреса предприятий. Поступление данных о предприятиях может происходить все время. На основании этого не имеет смысла архивировать данные за какой-либо период. Можно предусмотреть индивидуальную архивацию данных, например, в случае реорганизации или закрытия данного конкретного предприятия. Состав объекта «Организации»представлен в табл. 1: Таблица 1.
Наимено-вание элемента
|
Описание
|
Источник данных
|
Тип значения
|
Использование
|
Ограни-чения
|
Важность
|
Связи
|
Номер
|
Порядковый номер пред-приятия
|
Данные фор-мируются ав-томатически
|
Целочис-ленный
|
Составление отчетных документов
|
Только чтение
|
определяющий
|
С всеми ос-тальными элементами
|
Название
|
Полное наи-менование организации
|
Отдел сбора информации
|
Текст
|
Составление отчетных документов
|
Чтение и измене-ние
|
Связывание данной записи с конкретной организацией
|
С элементом “Номер”
|
Страна
|
Наименова-ние страны
|
Отдел сбора информации
|
Текст
|
Составление отчетных документов
|
Чтение и измене-ние
|
Связывание данной записи с конкретной организацией
|
С элементом “Номер”
|
Адрес
|
Местонахож-дение пред-приятия
|
Отдел сбора информации
|
Текст
|
Составление отчетных документов
|
Чтение и измене-ние
|
Связывание данной записи с конкретной организацией
|
С элементом “Номер”
|
Телефон
|
Телефоны предприятия
|
Отдел сбора информации
|
Текст
|
Составление отчетных документов
|
Чтение и измене-ние
|
Связывание данной записи с конкретной организацией
|
С элементом “Номер”
|
Виды деятельности
|
Список видов деятельности предприятия
|
Отдел сбора информации
|
Таблица, содержа-щая шифры и наимено-вания видов деятель-ности
|
Составление отчетных документов
|
Чтение и измене-ние
|
Определяется использованием
|
С элементом “Номер” и объектом “Виды деятель-ности”
|
Произво-димые товары и услуги
|
Список това-ров и услуг, производи-мых пред-приятием
|
Отдел сбора информации
|
Таблица, содержа-щая наи-менова-ния това-ров и ус-луг и це-ны
|
Составление отчетных документов
|
Чтение и измене-ние
|
Определяется использованием
|
С элементом “Номер” и объектом “То-вары и ус-луги”
|
Опера-тивная информа-ция
|
Список зап-росов, объ-явлений предприятия
|
Отдел сбора информации
|
Таблица, содержа-щая зап-росы
|
Составление отчетных документов
|
Чтение и измене-ние
|
Определяется использованием
|
С элементом “Номер” и объектом “Запросы”
|
№ квартала регистрации
|
№ квартала регистрации
предприятия
|
Отдел сбора информации
|
Целочис-ленный
|
Составление отчетных документов
|
Чтение и измене-ние
|
Связывание данной записи с конкретной организацией
|
С элементом “Номер
|
Год регистрации
|
Год регистрациипредприятия
|
Отдел сбора информации
|
Целочис-ленный
|
Составление отчетных документов
|
Чтение и измене-ние
|
Связывание данной записи с конкретной организацией
|
С элементом “Номер
|
№ квартала снятия с регистрации
|
№ квартала снятия с регистрации предприятия
|
Отдел сбора информации
|
Целочис-ленный
|
Составление отчетных документов
|
Чтение и измене-ние
|
Связывание данной записи с конкретной организацией
|
С элементом “Номер
|
Год снятия с регистрации
|
Год снятия с регистрации предприятия
|
Отдел сбора информации
|
Целочис-ленный
|
Составление отчетных документов
|
Чтение и измене-ние
|
Связывание данной записи с конкретной организацией
|
С элементом “Номер
|
Объект данных «Виды деятельности» содержит в себе список видов деятельности для всех предприятий базы данных. Ввод и коррекция данных в этом объекте производятся на основании нормативных документов. Данные, хранящиеся в этом объекте, используются при составлении тех выходных документов, в которых указываются виды деятельности предприятий, а также для обработки данных о предприятиях в соответствии с их видами деятельности. Поступление данных о видах деятельности может происходить все время. На основании этого не имеет смысла архивировать данные за какой-либо период. Можно предусмотреть индивидуальную архивацию данных. Состав объекта «Виды деятельности» представлен в табл. 2. Объект данных «Товары и услуги» содержит в себе список всех товаров и услуг, производимых всеми предприятиями, зарегистрированными в базе данных. Ввод и коррекция данных в этом объекте производятся на основании информации, полученной от предприятий. Данные, хранящиеся в этом объекте, используются при составлении тех выходных документов, в которых указываются товары и услуги, производимые предприятиями, а также для обработки данных о предприятиях в соответствии с производимыми товарами и услугами. Поступление данных о товарах и услугах может происходить все время. На основании этого не имеет смысла архивировать данные за какой-либо период. Можно предусмотреть индивидуальную архивацию данных. Состав объекта «Товары и услуги» представлен в табл. 3. Таблица 2.
Наимено-вание элемента
|
Описание
|
Источник данных
|
Тип значения
|
Использование
|
Ограни-чения
|
Важность
|
Связи
|
Шифр
|
Шифр вида деятельности
|
Нормативные документы
|
Целочис-ленный
|
Составление отчетных документов
|
Чтение и измене-ние
|
Определяющий
|
С всеми ос-тальными элементами и элементом “Виды деятельности” объекта “Организации”
|
Наимено-вание
|
Полное наи-менование вида дея-тельности
|
Нормативные документы
|
Текст
|
Составление отчетных документов
|
Чтение и измене-ние
|
Определяется использованием
|
С элементом “Номер”
|
Таблица 3.
Наимено-вание элемента
|
Описание
|
Источник данных
|
Тип значения
|
Использование
|
Ограни-чения
|
Важность
|
Связи
|
Номер
|
Номер товара, услуги в списке
|
Данные фор-мируются ав-томатически
|
Целочис-ленный
|
Составление отчетных документов
|
Только чтение
|
Определяющий
|
С всеми ос-тальными элементами и элементом “Произ-водимые товары и услуги” объекта “Организации”
|
Наимено-вание
|
Полное наи-менование товара, услу-ги
|
Отдел сбора информации
|
Текст
|
Составление отчетных документов
|
Чтение и измене-ние
|
Определяется использовани-ем
|
С элементом “Номер”
|
Объект данных «Запросы» содержит в себе список оперативной информации, предоставляемой предприятиями, зарегистрированными в базе данных. Ввод и коррекция данных в этом объекте производятся на основании информации, полученной от предприятий. Данные, хранящиеся в этом объекте, используются при составлении тех выходных документов, в которых указываются разнообразные запросы предприятий, а также для обработки данных о предприятиях в соответствии с их запросами. Поступление оперативных данных может происходить все время. На основании этого не имеет смысла архивировать данные за какой-либо период. Можно предусмотреть индивидуальную архивацию данных. Состав объекта «Запросы» представлен в табл. 4: Таблица 4.
Наимено-вание элемента
|
Описание
|
Источник данных
|
Тип значения
|
Использование
|
Ограни-чения
|
Важность
|
Связи
|
Номер
|
Номер запроса, в списке
|
Данные формируются автоматически
|
Целочис-ленный
|
Разделение запросов с одинаковым содержанием
|
Только чтение
|
Определяющий
|
Со всеми ос-тальными элементами и элементом “Оперативная информация” объекта “Организации”
|
Наимено-вание
|
Запрос предприятия
|
Отдел сбора информации
|
Текст
|
Составление отчетных документов
|
Чтение и измене-ние
|
Определяется использованием
|
С элементом “Номер”
|
На основании информации об объектах построим функциональную схему данных.
Сначала исследуем информационные потоки. Исследуя информацию об объектах и элементах данных, мы видим, что:
1) данные из отдела сбора информации поступают во все объекты;
2) данные из нормативных документов поступают в объект «Виды деятельности».
На основании этого строим первоначальную схему данных. Результаты построения представлены на рис.1.
Функциональная
Модель
|
Исследование потоков
Данных
| Данные, выявленные
В ходе анкетирования
|
    Отдел сбора информации
|
|
Организации
|
|
|
Запросы
|
|
|
Товары и услуги
|
 Нормативные документы
|
|
Виды деятельности
|
Рис.1. Первоначальная схема данных.
Затем исследуем организацию хранения данных. Исследуя информацию об объектах и элементах данных, мы видим, что:
1) объект «Организации» является главным, так как он содержит все данные о предприятиях, в том числе и о видах деятельности, производимых товарах и услугах и оперативную информацию;
2) объект «Виды деятельности» является первичным, так как, не являясь потребителем информации от других объектов, одновременно является источником информации для объекта «Организации»;
3) объект «Товары и услуги» является первичным, так как, не являясь потребителем информации от других объектов, одновременно является источником информации для объекта «Организации»;
4) объект «Запросы» является первичным, так как, не являясь потребителем информации от других объектов, одновременно является источником информации для объекта «Организации»;
5) внешним источником информации для объектов «Организации», «Товары и услуги», «Запросы» является отдел сбора информации;
6) внешними источником информации для объекта «Виды деятельности» являются нормативные документы;
7) внешним приемником информации из объекта «Организации» являются отчетные документы.
На основании данной информации строим функциональную схему данных. Результаты построения представлены на рис.2.
| | | | | | | |
| | | |
Функциональный потребитель
| |
| | | | |
Функциональный потребитель
| |
|
| | | | |
|  | | |
|
| | |
Информация для отдельных лиц и органи-заций
| |
|
Рис.2. Функциональная схема данных.
1.2. НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ ДО ТРЕТЬЕЙ НОРМАЛЬНОЙ ФОРМЫ
1.2.1. Первая нормальная форма
Ненормализованное отношение для базы данных «Предприятие» показано в табл. 5. Ненормализованным это отношение является потому, что в некоторых ячейках таблицы имеется более одного значения.
Таблица 5. Ненормализованное отношение
№
|
Название
|
Страна
|
Адрес
|
Теле-фон
|
Шифр
|
Наименование вида деятель-ности
|
Номер товара, услуги
|
Наименова-ние товара, услуги
|
Цена
|
Номер запроса
|
Оператив-ная инфор-мация
|
№ квартала регистрации
|
Год регистрации
|
№ квартала снятия с регистрации
|
Год снятия с регистрации
|
1020
|
ООО «Трайпл»
|
Россия
|
г. Краснодар, ул. Офицерс-кая, 55 оф. 123, 124, 125
|
550-551
|
91200
85800
|
Производство программных продуктов
Обучение работе на производимых программных продуктах
|
1205
1206
1207
|
Инсталляци-онная дискета
Документа-ция
Курс обуче-ния
|
150-00
130-00
500-00
|
6658
|
Требуется программист-сетевик
|
1
|
1999
|
4
|
2002
|
1156
|
ООО Фирма «Валио»
|
Россия
|
г. Краснодар, ул. Красная, 55 оф. 555
|
653-226
|
91300
|
Продажа лекарственных препаратов
|
1605
1606
1607
|
«Энам-2,5»
«Энам-5»
«Энам-10»
|
15-00
25-00
55-00
|
9855
|
Продаются аптекарские весы
|
2
|
1999
|
4
|
2001
|
1502
|
Магазин «Планета»
|
Россия
|
г. Краснодар, ул. Северная, 345
|
555-890
|
91100
|
Торговая деятельность
|
2101
|
Набор сле-сарных инс-трументов
|
700-00
|
11250
11256
|
Требуется продавец
Продается кассовый аппарат
|
3
|
1999
|
1
|
2000
|
Произведем нормализацию данного отношения. Цель нормализации – на основе табл. 5 создать таблицу, в которой на пересечении любых строки и столбца находится только одно значение. Для этого продублируем значения атрибутов «Шифр», «Наименование вида деятельности», «Регистрационный номер товара, услуги», «Наименование товара, услуги», «Цена», «Регистрационный номер запроса», «Оперативная информация». При дублировании значений атрибутов, связанных с видами деятельности и товарами и услугами, произведем распределение данных о товарах и услугах по соответствующим видам деятельности. Значения атрибутов, связанных с оперативной информацией, заносим в первую нормальную форму только по одному разу. Результат представлен в табл. 6. В графическом виде первая нормальная форма представлена на рис. 3.
Первая нормальная форма имеет следующие особенности:
1) производимые товары и услуги связаны с видами деятельности – не может быть такого случая, чтобы какой-либо товар или услуга не был привязан к какому-либо виду деятельности и наоборот;
2) оперативная информация никак не связана с видами деятельности и товарами и услугами, в определенных случаях кортежей с оперативной информацией может быть больше, чем кортежей с товарами и услугами (см. например две последние строки табл. 6).
В связи с этим возникает неопределенность с тем, какие атрибуты включать в состав первичного ключа. Атрибут «Номер» однозначно входит в состав этого ключа. Атрибуты «Шифр», «Номер товара, услуги», «Номер запроса» также должны входить в состав первичного ключа. Если заданы номер предприятия, шифр вида деятельности, номер товара, услуги и номер запроса (даже если некоторые из них содержат значение «Пусто»), то можно однозначно определить значения всех остальных атрибутов, входящих в состав данного отношения. Поэтому включаем в состав первичного ключа атрибуты «Номер», «Шифр», «Номер товара, услуги» и «Номер запроса» с допущением, что некоторые из них (но не все сразу) могут иметь значение «Пусто».
Таблица 6. 
Первая нормальная форма
Первичный ключ
№
|
Номер товара, услуги
|
Номер запро-са
|
Шифр
|
Название
|
Страна
|
Адрес
|
Теле-фон
|
Наименование вида деятель-ности
|
Наименова-ние товара, услуги
|
Цена
|
Оператив-ная инфор-мация
|
№ квартала регистрации
|
Год регистрации
|
№ квартала снятия с регистрации
|
Год снятия с регистрации
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
1
|
1999
|
4
|
2002
|
1020
|
1205
|
6658
|
91200
|
ООО «Трайпл»
|
Россия
|
г. Краснодар, ул. Офицерс-кая, 55 оф. 123, 124, 125
|
550-551
|
Производство программных продуктов
|
Инсталляци-онная диске-та
|
150-00
|
Требуется програм-мист-сете-вик
|
2
|
1999
|
4
|
2001
|
1020
|
1206
|
|
91200
|
ООО «Трайпл»
|
Россия
|
г. Краснодар, ул. Офицерс-кая, 55 оф. 123, 124, 125
|
550-551
|
Производство программных продуктов
|
Документа-ция
|
130-00
|
|
3
|
1999
|
1
|
2000
|
1020
|
1207
|
|
85800
|
ООО «Трайпл»
|
Россия
|
г. Краснодар, ул. Офицерская, 55 оф. 123, 124, 125
|
550-551
|
Обучение ра-боте на произ-водимых про-граммных продуктах
|
Курс обуче-ния
|
500-00
|
|
|
|
|
|
1156
|
1605
|
9855
|
91300
|
ООО Фирма «Валио»
|
Россия
|
г. Краснодар, ул. Красная, 55 оф. 555
|
653-226
|
Продажа ле-карственных препаратов
|
«Энам-2,5»
|
15-00
|
Продаются аптекарс-кие весы
|
|
|
|
|
1156
|
1606
|
|
91300
|
ООО Фирма «Валио»
|
Россия
|
г. Краснодар, ул. Красная, 55 оф. 555
|
653-226
|
Продажа ле-карственных препаратов
|
«Энам-5»
|
25-00
|
|
|
|
|
|
1156
|
1607
|
|
91300
|
ООО Фирма «Валио»
|
Россия
|
г. Краснодар, ул. Красная, 55 оф. 555
|
653-226
|
Продажа ле-карственных препаратов
|
«Энам-10»
|
55-00
|
|
|
|
|
|
1502
|
2101
|
11250
|
91100
|
Магазин «Планета»
|
Россия
|
г. Краснодар, ул. Северная, 345
|
555-890
|
Торговая дея-тельность
|
Набор сле-сарных инс-трументов
|
700-00
|
Требуется продавец
|
|
|
|
|
1502
|
|
11256
|
|
Магазин «Планета»
|
Россия
|
г. Краснодар, ул. Северная, 345
|
555-890
|
|
|
|
Продается кассовый аппарат
|
|
|
|
|
Обработка экземпляров отношения, находящегося в первой нормальной форме, связана с определенными трудностями. Эти трудности существуют потому, что первичный ключ первой нормальной формы состоит из четырех разных атрибутов. Атрибут «Номер» определяет атрибуты данных о предприятии, атрибут «Шифр» определяет атрибуты видов деятельности, атрибут «Номер товара, услуги» определяет атрибуты товаров и услуг, атрибут «Номер запроса» определяет оперативную информацию. Поэтому невозможно производить раздельную обработку данных об организациях, видах деятельности, товарах и услугах, оперативной информации – имеют место аномалии обработки информации. Аномалии включения связаны с невозможностью ввода информации только об организации (тип 1), виде деятельности (тип 2), товаре, услуге (тип 3), оперативной информации (тип 4). Должна указываться вся информация сразу. 
Рис.3. Графическое представление первой нормальной формы.Аномалии удаления связаны с невозможностью удаления информации только об организации (тип 1), виде деятельности (тип 2), товаре, услуге (тип 3), оперативной информации (тип 4). Должна удаляться вся информация сразу. Кроме того, уже само допущение о возможности присваивания ключевым атрибутам значения «Пусто» является аномалией. Для устранения этих аномалий необходимо разделить данные о предприятиях, видах деятельности, товарах и услугах, оперативной информации в разные отношения – перейти ко второй нормальной форме. 1.2.2. ВТОРАЯ НОРМАЛЬНАЯ ФОРМА
Для того, чтобы перейти от первой нормальной формы ко второй, надо отношение, представленное в табл. 6, разделить на четыре отдельных отношения, в одном из которых будут данные о предприятиях, в другом – данные о видах деятельности, в третьем – данные о товарах, услугах, в четвертом – оперативная информация. Первому отношению присвоим наименование «Организации», второму – «Виды деятельности», третьему – «Товары и услуги», четвертому – «Оперативная информация». Отношение «Организации» представлено в табл. 7 и на рис. 4, отношение «Виды деятельности» представлено в табл. 8 и на рис. 5, отношение «Товары и услуги» представлено в табл. 9 и на рис. 6, отношение «Оперативная информация» представлено в табл. 10 и на рис. 7. Таблица 7. Организации
Номер
|
Название
|
Страна
|
Адрес
|
Телефон
|
…
|
…
|
…
|
…
|
…
|
Рис.4. Графическое представление отношения «Организации». Таблица 8. Виды деятельности
Шифр
|
Наименование вида деятельности
|
…
|
…
|
Рис.5. Графическое представление отношения «Виды деятельности». Таблица 9. Товары и услуги
Номер товара, услуги
|
Наименование товара, услуги
|
Номер
|
Цена
|
…
|
…
|
…
|
…
|
Рис.6. Графическое представление отношения «Товары и услуги». Таблица 10. Оперативная информация
Номер
|
Номер запроса
|
Оперативная информация
|
…
|
…
|
…
|
Рис.7. Графическое представление отношения «Оперативная информация».Также создадим отношение, показывающее распределение видов деятельности по предприятиям и назовем его «Виды деятельности организации». Это отношение представлено в табл. 11 и на рис. 8. Таблица 11. Виды деятельности организации
Рис.8. Графическое представление отношения «Виды деятельности организации».Первичным ключом отношения «Организации» является атрибут «Номер». Первичным ключом отношения «Виды деятельности» является атрибут «Шифр». Первичным ключом отношения «Товары и услуги» являются атрибуты «Номер» и «Номер товара, услуги». Первичным ключом отношения «Виды деятельности организации» являются атрибуты «Шифр» и «Номер». Первичным ключом отношения «Оперативная информация» являются атрибуты «Номер» и «Номер запроса». Все аномалии, выявленные в первой нормальной форме, во второй нормальной форме устранены. Теперь можно вводить и удалять данные раздельно по организациям, видам деятельности, товарам, услугам, оперативной информации. Рассмотрим теперь вторую нормальную форму на предмет определения аномалий. В каждом из отношений «Организации», «Виды деятельности», «Оперативная информация», «Виды деятельности организации», первичный ключ однозначно определяет весь кортеж данных. В отношении «Товары и услуги» весь первичный ключ однозначно определяет атрибут «Цена», а атрибут «Наименование товара, услуги» определяется не всем первичным ключом, а его частью. Существующие аномалии связаны с тем, что одному и тому же наименованию товара, услуги могут соответствовать разные цены в зависимости от значения атрибута «Номер». Имеются следующие аномалии: 1) аномалия обновления – в том случае, если данный товар или услуга, уже связанный с каким-либо предприятием, связывается с другим предприятием, то цена может быть другой. Возникает неопределенность – или каждый раз просматривать отношение, представленное в табл. 9, и каждый раз вручную изменять вид, или нарушать непротиворечивость данных, когда в некоторых кортежах цена будет изменена, а в некоторых - нет; 2) аномалия удаления (тип 1) – при удалении данных о предприятии также удаляются данные о товаре или услуге, и если этот товар или услуга были связаны только с этим предприятием, то возможна потеря данных о них; 3) аномалия удаления (тип 2) – при удалении данных о товаре или услуге также удаляются данные о предприятии, и если это предприятие было связано только с этим товаром или услугой, то возможна потеря данных о нем. Тот факт, что пока какой-либо товар или услуга не связаны с каким-либо предприятием, невозможно указать цену, аномалией не является. Для устранения этих аномалий необходимо выделить данные о товарах и услугах и данные об их ценах в разные отношения – перейти к третьей нормальной форме. 1.2.3. ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА
Для того, чтобы перейти от второй нормальной формы к третьей, надо из отношения «Товары и услуги», представленного в табл. 9, выделить информацию о ценах в отдельное отношение, которому присвоить имя «Цены». В самом отношении «Товары и услуги» останутся данные только о наименованиях товаров и услуг, а в отношении «Цены» будут присутствовать данные только о ценах на товары и услуги по организациям. Отношение «Товары и услуги» представлено в табл. 12 и рис. 9, отношение «Цены» представлено в табл. 13 и рис. 10. Остальные отношения не требуют дальнейших преобразований, так как ключевые атрибуты каждого из них однозначно определяют неключевые, и между неключевыми атрибутами нет никакой зависимости друг от друга. Можно сказать, что отношения «Организации», «Виды деятельности», «Оперативная информация», «Виды деятельности организации» находятся в третьей нормальной форме. Таблица 12. Товары и услуги
Номер товара, услуги
|
Наименование товара, услуги
|
…
|
…
|
Рис.9. Графическое представление отношения «Товары и услуги». Таблица 13. Цены
Номер товара, услуги
|
Номер
|
Цена
|
…
|
|
…
|
Рис.10. Графическое представление отношения «Цены». Первичным ключом отношения «Товары и услуги» является атрибут «Номер товара, услуги», первичным ключом отношения «Цены» являются атрибуты «Номер товара, услуги» и «Номер». Рассмотрим аномалии, выявленные в ходе анализа первой нормальной формы: 1) аномалия обновления – можно связывать любые товары или услуги с любыми предприятиями и проставлять любые необходимые цены; 2) аномалия удаления (тип 1) – при удалении данных о предприятии не происходит потеря данных о товаре или услуге; 3) аномалия удаления (тип 2) – при удалении данных о товаре или услуге не происходит потеря данных о предприятии. Итак, все аномалии, выявленные в ходе анализа второй нормальной формы, устранены. В результате нормализации получены семь отношений, находящихся в третьей нормальной форме. Эти отношения представлены в табл. 7, табл. 8, табл. 10, табл. 11, табл. 12, табл. 13 и на рис. 4, рис. 5, рис. 7, рис. 8, рис. 9, рис. 10. На этом процесс нормализации закончен. 1.3. ГРАФИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ДАННЫХ
Определим взаимосвязи между отношениями «Организации», «Виды деятельности», «Товары и услуги», «Цены», «Оперативная информация», «Виды деятельности организации». Исходными данными для этого являются следующие пункты: 1) одно предприятие может заниматься несколькими видами деятельности; 2) одно предприятие может иметь несколько производимых товаров и услуг; 3) одно предприятие может иметь несколько запросов оперативной информации или не иметь их совсем; 4) один и тот же вид деятельности может принадлежать нескольким предприятиям; 5) один и тот же товар может выпускаться несколькими предприятиями и по разным ценам; 6) каждый отдельный запрос оперативной информации принадлежит только одному конкретному предприятию. Взаимосвязи, построенные на основании этой информации, представлены на рис. 11. Рис.11. Взаимосвязи между объектами. Отношения «Организации», «Виды деятельности», «Товары и услуги», «Цены», «Оперативная информация», «Виды деятельности организации» после нормализации представлены следующим образом: 1) Номер – Название, Страна, Адрес, Телефон, № квартала регистрации, Год регистрации, № квартала снятия с регистрации, Год снятия с регистрации; 2) Шифр – Наименование вида деятельности; 3) Номер товара, услуги – Наименование товара, услуги; 4) Номер товара, услуги * Номер – Цена; 5) Номер запроса * Номер – Оперативная информация; 6) Номер * Шифр. В результате имеем следующее: 1. Каждое отношение, первичный ключ которого содержит один элемент данных, представляет объект. 2. Каждое отношение, первичный ключ которого содержит два элемента данных, являющихся первичными ключами других отношений, представляет взаимосвязи между объектами. В том случае, если отношение с двумя ключевыми элементами данных содержит неключевой элемент данных, отсутствующий в других отношениях, то это отношение представляет объект. На основании этого создадим графическое представление концептуальной модели данных. Результат представлен на рис. 12. Двойные стрелки соответствуют связи типа «ко многим».Номер – Название, Страна, Адрес, Телефон, № квартала регистрации, Год регистрации, № квартала снятия с регистрации, Год снятия с регистрации; Рис.12. Графическое представление концептуальной модели данных. 2. ПРОЕКТИРОВАНИЕ ЛОГИЧЕСКОЙ МОДЕЛИ ДАННЫХ ДЛЯ СЕТЕВОЙСУБД
При проектировании логической модели в качестве исходных данных возьмем концептуальную модель, представленную на рис. 12. 2.1. ВЫВОД ОБОБЩЕННОЙ СЕТЕВОЙ МОДЕЛИ
В концептуальной модели на рис. 12 прямоугольники представляют узлы, а стрелки – взаимосвязи между ними. На первом уровне находятся узлы «Виды деятельности», «Товары и услуги», «Организации». На втором уровне находятся узлы «Цены», «Виды деятельности организации» «Оперативная информация». Узлы первого уровня являются исходными, узлы второго уровня – порожденными. Для узла «Цены» исходными узлами являются «Организации» и «Товары и услуги». Для узла «Виды деятельности организации» исходными узлами являются «Организации» и «Виды деятельности». Для узла «Оперативная информация» исходным узлом является «Организации». Транзитивность отсутствует, так как все связи направлены только вертикально с одного уровня на другой, горизонтальных связей нет, уровней всего два (см. рис. 12). При проектировании логической модели данных для иерархической СУБД на основе концептуальной модели необходимо, чтобы у каждого порожденного узла был только один исходный. В нашем случае все исходные и порожденные узлы – отношения в третьей нормальной форме. Рассмотрим группу узлов «Органиации», «Виды деятельности», «Виды деятельности организации». В данном случае узел «Виды деятельности» можно сделать исходным, а узлы «Органиации» и «Виды деятельности организации» объединить. В результате получается конструкция, показанная на рис. 13. Рис.13. Группа узлов «Органиации», «Виды деятельности», «Виды деятельности организации».Рассмотрим группу узлов «Организации», «Товары и услуги», «Цены». В данном случае узел «Организации» можно сделать исходным, а узлы «Товары и услуги» и «Цены» объединить. В результате получается конструкция, показанная на рис. 14. Для группы узлов «Организации» и «Оперативная информация» никаких преобразований производить не нужно. Рис.14. Группа узлов «Организации», «Товары и услуги», «Цены».Для получения полной логической модели объединим группы узлов, представленные на рис. 13, рис. 14. Узел «Организации + Виды деятельности организации» (рис. 13) базируется на узле «Организации», поэтому при создании полной логической модели эти узлы объединим в один узел. Полученная логическая модель представлена на рис. 15. Рис.15. Графическое представление логической модели данных для иерархической СУБД. 2.2. РЕАЛИЗАЦИЯ ВЗАИМОСВЯЗЕЙ, НЕ ОТОБРАЖЕННЫХ В ЛОГИЧЕСКОЙ МОДЕЛИ, НО НА САМОМ ДЕЛЕ СУЩЕСТВУЮЩИХ
Логическая модель, представленная на рис.15, не требует каких-либо изменений, так как все существующие взаимосвязи уже отображены на ней. 3. ПРОЕКТИРОВАНИЕ ЛОГИЧЕСКОЙ МОДЕЛИ ДАННЫХ ДЛЯ РЕЛЯЦИОННОЙ СУБД
При проектировании логической модели в качестве исходных данных возьмем концептуальную модель, представленную на рис. 12. Отношения, входящие в состав концептуальной модели, представлены в табл. 7, табл. 8, табл. 10, табл. 11, табл. 12, табл. 13 и графически соответственно на рис. 4, рис. 5, рис. 7, рис. 8, рис. 9, рис. 10. Атрибутами отношения «Организации» являются «Номер», «Название», «Страна», «Адрес», «Телефон». Первичным ключом этого отношения является атрибут «Номер». Значения этого ключа уникальны, так как не существует двух кортежей с одинаковыми номерами организаций. Атрибутами отношения «Виды деятельности» являются «Шифр», «Наименование вида деятельности». Первичным ключом этого отношения является атрибут «Шифр». Значения этого ключа уникальны, так как не существует двух кортежей с одинаковыми шифрами видов деятельности. Атрибутами отношения «Товары и услуги» являются «Номер товара, услуги», «Наименование товара, услуги». Первичным ключом этого отношения является атрибут «Номер товара, услуги». Значения этого ключа уникальны, так как не существует двух кортежей с одинаковыми номерами товаров и услуг. Атрибутами отношения «Цены» являются «Номер товара, услуги», «Номер», «Цена». Первичным ключом этого отношения являются атрибуты «Номер товара, услуги», «Номер». Значения этого ключа уникальны, так как не существует двух кортежей с одинаковыми номерами товаров и услуг и организаций. Атрибутами отношения «Оперативная информация» являются «Номер запроса», «Номер», «Запрос». Ключом этого отношения являются атрибуты «Номер запроса» и «Номер». Данные номера запроса и организации могут пересекаться только один раз, образуя уникальную комбинацию. Атрибутами и ключом отношения «Виды деятельности организации» являются «Номер» и «Шифр». Данные номер организации и шифр вида деятельности могут пересекаться только один раз, образуя уникальную комбинацию. Все вышеописанные отношения показывают пользовательское представление о логической модели базы данных «Предприятие» для реляционной СУБД. Каждый прямоугольник концептуальной модели рис. 12 является отдельным отношением, отражающим представление пользователя в удобном для него формате (см. табл. 7, табл. 8, табл. 10, табл. 11, табл. 12, табл. 13). В данной модели имеет место избыточность ключевых атрибутов, например, атрибут «Номер» является первичным атрибутом отношения «Организации» и одновременно входит в составной ключ отношений «Цены», «Оперативная информация», «Виды деятельности организаций». В дальнейшем эта избыточность будет устранена. 4. ФИЗИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
В соответствии с заданием задан метод доступа физической модели посредством хеширования. Основной принцип такого метода доступа – несколько значений ключей ссылаются на один и тот же физический адрес записи. Несколько записей, соответствующих этим ключам, объединены в цепочку. Конкретное положение искомой записи в цепочке для каждого конкретного значения ключа определяется с помощью специальной процедуры. Для организации цепочек в каждую информационную таблицу было добавлено поле «Далее», содержащее адрес следующего элемента цепочки или 0, указывающий на конец цепочки. Для реализации данного метода доступа для каждого отношения, представленного в табл. 7, табл. 8, табл. 10, табл. 11, табл. 12, табл. 13, требуется создать индексную таблицу, содержащую значения ключей, а также поле «Адрес», содержащее в себе номер первой записи в цепочке. В базе данных «Предприятие» присутствует архив. В нем содержится информация, удаленная из текущей базы, например, организации, прекратившие свое существование, товары и услуги, больше не выпускаемые данными организациями и т.д. Архивные таблицы созданы для отношений «Организации», «Цены», «Виды деятельности организации», «Оперативная информация». Структура архивных таблиц полностью соответствует структуре указанных отношений. В соответствующих индексных таблицах присутствует специальное поле «Архив», указывающее на то, что данный ключ указывает на цепочку в архивной информационной таблице. Для реализации квартальных отчетов во все таблицы (и информационные, и индексные) введены поля «Дата регистрации» и «Дата архивации». Для реализации механизма выборок по заданным данным (товарам, услугам, видам деятельности, адресной информации и т.д.) состав ключевой информации значительно расширен по сравнению с указанной выше. Выбор информации для дальнейшей обработки производится по индексным таблицам. Для этого в каждую индексную таблицу введено поле «Флаг». Перечислим состав полей индексных таблиц: 1) индексная таблица для отношения «Организации» содержит в себе поля «Номер», «Название», «Город», «Улица», «Дом», «Дата регистрации», «Адрес», «Флаг», «Архив»; 2) индексная таблица для отношения «Товары и услуги» содержит в себе поля «Номер», «Наименование товара, услуги», «Адрес», «Флаг»; 3) индексная таблица для отношения «Виды деятельности» содержит в себе поля «Шифр», «Наименование вида деятельности», «Адрес», «Флаг»; 4) индексная таблица для отношения «Цены» содержит в себе поля «Номер», «Номер товара, услуги», «Наименование товара, услуги», «Дата регистрации», «Адрес», «Флаг», «Архив»; 5) индексная таблица для отношения «Оперативная информация» содержит в себе поля «Номер», «Номер запроса», «Дата регистрации», «Адрес», «Флаг», «Архив»; 6) индексная таблица для отношения «Виды деятельности организации» содержит в себе поля «Номер», «Шифр», «Наименование вида деятельности», «Дата регистрации», «Адрес», «Флаг», «Архив». Примеры хэш-доступа показаны на рисунках 16 … 21 :
Исходные ключи
|
Преобра-зованные ключи
|
Номер в цепочке
|
Адрес
|
Содержимое записи
|
Указа-тель цепочки
|
 226; ООО «Транзит»; Краснодар; ул. Красная; 25; 12/03/2000
|
12
|
1
|
12
|
226; ООО «Транзит»; Краснодар; ул. Красная; 25; 12/03/2000
|
14
|
    237; ИЧП «Марк»; Краснодар; ул. Стасова; 35; 25/05/2000
|
13
|
1
|
13
|
237; ИЧП «Марк»; Краснодар; ул. Стасова; 35; 25/05/2000
|
15
|
285; ИЧП «Астра»; Краснодар; ул. Селезнева; 123; 30/11/2000
|
12
|
2
|
14
|
285; ИЧП «Астра»; Краснодар; ул. Селезнева; 123; 30/11/2000
|
0
|
    302; ТОО «ТОРОС»; Краснодар; ул. КИМ; 55; 05/02/2001
|
13
|
2
|
15
|
302; ТОО «ТОРОС»; Краснодар; ул. КИМ; 55; 05/02/2001
|
0
|
Рис.16. Пример применения метода доступа последством хэширования к отношению «Организации».
Исходные ключи
|
Преобра-зованные ключи
|
Номер в цепочке
|
Адрес
|
Содержимое записи
|
Указа-тель цепочки
|
   12; Шины 12х5
|
8
|
1
|
8
|
12; Шины 12х5
|
23
|
  18; Шприц одноразовый 1 см3
|
11
|
1
|
11
|
18; Шприц одноразовый 1 см3
|
29
|
    25; Клавиатура 101-клавишная
|
8
|
2
|
23
|
25; Клавиатура 101-клавишная
|
55
|
48; Труба оцинкованная Ду 60
|
11
|
2
|
29
|
48; Труба оцинкованная Ду 60
|
80
|
Рис.17. Пример применения метода доступа последством хэширования к отношению «Товары и услуги».
Исходные ключи
|
Преобра-зованные ключи
|
Номер в цепочке
|
Адрес
|
Содержимое записи
|
Указа-тель цепочки
|
91200; Мелкооптовая торговля
|
5
|
1
|
5
|
91200; Мелкооптовая торговля
|
0
|
      92500; Распространение программных продуктов
|
9
|
1
|
9
|
92500; Распространение программных продуктов
|
17
|
   98800; Проведение отделочных работ
|
9
|
2
|
17
|
98800; Проведение отделочных работ
|
38
|
 92250; Перевозки грузов до 1 т
|
9
|
3
|
38
|
92250; Перевозки грузов до 1 т
|
44
|
92251; Перевозки грузов до 3 т
|
9
|
4
|
44
|
92251; Перевозки грузов до 3 т
|
0
|
 92262; Пассажирские перевозки
|
55
|
1
|
55
|
92262; Пассажирские перевозки
|
0
|
Рис.18. Пример применения метода доступа последством хэширования к отношению «Виды деятельности»
Исходные ключи
|
Преобра-зованные ключи
|
Номер в цепочке
|
Адрес
|
Содержимое записи
|
Указа-тель цепочки
|
    55; 12; Шины 12х5; 12/01/2000
|
27
|
1
|
27
|
55; 12; Шины 12х5; 12/01/2000
|
35
|
 88; 18; Шприц одноразовый 1 см3; 25/02/2000
|
27
|
2
|
35
|
88; 18; Шприц однора-зовый 1 см3; 25/02/2000
|
0
|
125; 25; Клавиатура 101-клавишная; 02/03/2000
|
44
|
1
|
44
|
125; 25; Клавиатура 101-клавишная; 02/03/2000
|
0
|
 55; 48; Труба оцинкованная Ду 60; 12/03/2000
|
98
|
1
|
98
|
55; 48; Труба оцинко-ванная Ду 60; 12/03/2000
|
0
|
Рис.19. Пример применения метода доступа последством хэширования к отношению «Цены».
Исходные ключи
|
Преобра-зованные ключи
|
Номер в цепочке
|
Адрес
|
Содержимое записи
|
Указа-тель цепочки
|
    27; 55; 08/05/2000
|
52
|
1
|
52
|
27; 55; 08/05/2000
|
65
|
27; 68; 12/06/2000
|
59
|
1
|
59
|
27; 68; 12/06/2000
|
0
|
    55; 120; 25/07/2000
|
52
|
2
|
65
|
55; 120; 25/07/2000
|
0
|
68; 135; 02/08/2000
|
78
|
1
|
78
|
68; 135; 02/08/2000
|
0
|
Рис.20. Пример применения метода доступа последством хэширования к отношению «Оперативная информация».
Исходные ключи
|
Преобра-зованные ключи
|
Номер в цепочке
|
Адрес
|
Содержимое записи
|
Указа-тель цепочки
|
57; 91200; Мелкооптовая торговля; 25/08/2000
|
23
|
1
|
23
|
57; 91200; Мелкооптовая торговля; 25/08/2000
|
95
|
 57; 92500; Распространение программных продуктов; 25/08/2000
|
55
|
1
|
55
|
57; 92500; Распрост-ранение программных продуктов; 25/08/2000
|
106
|
    78; 98800; Проведение отделочных работ; 22/12/2000
|
88
|
1
|
88
|
78; 98800; Проведение отделочных работ; 22/12/2000
|
125
|
155; 92250; Перевозки грузов до 1 т; 02/02/2001
|
23
|
2
|
95
|
155; 92250; Перевозки грузов до 1 т; 02/02/2001
|
0
|
155; 92251; Перевозки грузов до 3 т; 02/02/2001
|
55
|
2
|
106
|
155; 92251; Перевозки грузов до 3 т; 02/02/2001
|
0
|
   155; 92262; Пассажирские перевозки; 02/02/2001
|
88
|
2
|
125
|
155; 92262; Пассажирс-кие перевозки; 02/02/2001
|
0
|
Рис.21. Пример применения метода доступа последством хэширования к отношению «Виды деятельности»
5. ЛИСТИНГ ПРОГРАММЫ
#include <vcl.h>
#pragma hdrstop
#include "TMain.h"
#include "TSprVidDeyatel.h"
#include "TSprGoods.h"
#include "TDMMain.h"
#include "TEditFoundation.h"
#include "Report1.h"
#include "Report2.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma link "RxLookup"
#pragma link "RXSplit"
#pragma resource "*.dfm"
TMain *Main;
//---------------------------------------------------------------------------
__fastcall TMain::TMain(TComponent* Owner)
: TForm(Owner)
{
aWhere = " where ";
}
//---------------------------------------------------------------------------
void __fastcall TMain::ActGoodsExecute(TObject *Sender)
{
TSprGoods *SprGoods = new TSprGoods(this);
SprGoods->ShowModal();
delete SprGoods;
}
//---------------------------------------------------------------------------
void __fastcall TMain::ActVidDeyatelExecute(TObject *Sender)
{
TSprVidDeyatel *SprVidDeyatel = new TSprVidDeyatel(this);
SprVidDeyatel->ShowModal();
delete SprVidDeyatel;
}
//---------------------------------------------------------------------------
void __fastcall TMain::ActCloseExecute(TObject *Sender)
{
Close();
}
//---------------------------------------------------------------------------
void __fastcall TMain::SpeedButton1Click(TObject *Sender)
{
TEditFoundation *EditFoundation = new TEditFoundation(this);
DMMain->Foundation->Insert();
EditFoundation->ShowModal();
delete EditFoundation;
}
//---------------------------------------------------------------------------
void __fastcall TMain::SpeedButton2Click(TObject *Sender)
{
TEditFoundation *EditFoundation = new TEditFoundation(this);
DMMain->Foundation->Locate("ID",DMMain->qryFoundation->FieldByName("ID")->AsInteger,TLocateOptions());
DMMain->Foundation->Edit();
EditFoundation->ShowModal();
delete EditFoundation;
}
//---------------------------------------------------------------------------
void __fastcall TMain::SetMacros()
{
DMMain->qryFoundation->Close();
/*if((!RxDBLookupCombo1->KeyValue.IsNull())||(!RxDBLookupCombo1->KeyValue.IsNull()))
DMMain->qryFoundation->MacroByName("mac1")->AsString = aWhere;*/
if(!RxDBLookupCombo1->KeyValue.IsNull())
{
DMMain->qryFoundation->MacroByName("macW")->AsString = aWhere ;
DMMain->qryFoundation->MacroByName("mac1")->AsString =
" inner join cost g on g.foundation_id = f.id ";
DMMain->qryFoundation->MacroByName("mac3")->AsString =
" g.goods_id = " + RxDBLookupCombo1->KeyValue;
}
else
{
DMMain->qryFoundation->MacroByName("mac1")->AsString = "";
DMMain->qryFoundation->MacroByName("mac3")->AsString = "";
DMMain->qryFoundation->MacroByName("macW")->AsString = "";
}
if(!RxDBLookupCombo2->KeyValue.IsNull())
{
DMMain->qryFoundation->MacroByName("macW")->AsString = aWhere ;
DMMain->qryFoundation->MacroByName("mac2")->AsString =
" inner join DeyatFnd df on df.foundation_id = f.id ";
if(!RxDBLookupCombo1->KeyValue.IsNull())
DMMain->qryFoundation->MacroByName("mac4")->AsString =
" and df.viddeyatel_id = " + RxDBLookupCombo2->KeyValue;
else
DMMain->qryFoundation->MacroByName("mac4")->AsString =
" df.viddeyatel_id = " + RxDBLookupCombo2->KeyValue;
}
else
{
DMMain->qryFoundation->MacroByName("mac2")->AsString = "";
DMMain->qryFoundation->MacroByName("mac4")->AsString = "";
}
Reg_UnReg();
DMMain->qryFoundation->SQL->Text;
DMMain->qryFoundation->Open();
}
//---------------------------------------------------------------------------
void __fastcall TMain::Button1Click(TObject *Sender)
{
SetMacros();
}
//---------------------------------------------------------------------------
void __fastcall TMain::Reg_UnReg()
{
if((ComboBox1->ItemIndex==0)||(Edit1->Text.IsEmpty()))
{
Edit1->Text = "";
ComboBox1->ItemIndex = 0;
if(RxDBLookupCombo2->KeyValue.IsNull())
DMMain->qryFoundation->MacroByName("mac4")->AsString = "";
if(RxDBLookupCombo2->KeyValue.IsNull()&&RxDBLookupCombo1->KeyValue.IsNull())
DMMain->qryFoundation->MacroByName("macW")->AsString = "";
}
else
if(CheckBox1->Checked)
{
if(!RxDBLookupCombo2->KeyValue.IsNull())
{
DMMain->qryFoundation->MacroByName("mac4")->AsString =
DMMain->qryFoundation->MacroByName("mac4")->AsString +
" and f.beg_kv = " + AnsiString(ComboBox1->ItemIndex) +
" and f.beg_year = " + Edit1->Text;
}
else
{
if(!RxDBLookupCombo1->KeyValue.IsNull())
{ DMMain->qryFoundation->MacroByName("mac4")->AsString =
" and f.beg_kv = " + AnsiString(ComboBox1->ItemIndex) +
" and f.beg_year = " + Edit1->Text;
}
else
{ DMMain->qryFoundation->MacroByName("macW")->AsString = aWhere;
DMMain->qryFoundation->MacroByName("mac4")->AsString =
" f.beg_kv = " + AnsiString(ComboBox1->ItemIndex) +
" and f.beg_year = " + Edit1->Text;
}
}
}
else
{
if(!RxDBLookupCombo2->KeyValue.IsNull())
{
DMMain->qryFoundation->MacroByName("mac4")->AsString =
DMMain->qryFoundation->MacroByName("mac4")->AsString +
" and f.end_kv = " + AnsiString(ComboBox1->ItemIndex) +
" and f.end_year = " + Edit1->Text;
}
else
{
if(!RxDBLookupCombo1->KeyValue.IsNull())
{
DMMain->qryFoundation->MacroByName("mac4")->AsString =
" and f.end_kv = " + AnsiString(ComboBox1->ItemIndex) +
" and f.end_year = " + Edit1->Text;
}
else
{
DMMain->qryFoundation->MacroByName("macW")->AsString = aWhere;
DMMain->qryFoundation->MacroByName("mac4")->AsString =
" f.end_kv = " + AnsiString(ComboBox1->ItemIndex) +
" and f.end_year = " + Edit1->Text;
}
}
}
}
//---------------------------------------------------------------------------
void __fastcall TMain::Rep_kvExecute(TObject *Sender)
{
//
runRep1(ComboBox1->Text +" "+Edit1->Text,RxDBLookupCombo1->Text,RxDBLookupCombo2->Text);
}
//---------------------------------------------------------------------------
void __fastcall TMain::N111Click(TObject *Sender)
{
QuickReport1->qryFoundation->ParamByName("id")->AsInteger =
DMMain->qryFoundation->FieldByName("id")->AsInteger;
QuickReport1->PreviewModal();
}
#include <vcl.h>
#pragma hdrstop
#include "TEditFoundation.h"
#include "TDMMain.h"
#include "TDMBase.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma link "RxDBComb"
#pragma resource "*.dfm"
TEditFoundation *EditFoundation;
//---------------------------------------------------------------------------
__fastcall TEditFoundation::TEditFoundation(TComponent* Owner)
: TForm(Owner)
{
}
//---------------------------------------------------------------------------
void __fastcall TEditFoundation::FormClose(TObject *Sender,
TCloseAction &Action)
{
if(DMMain->Foundation->State == dsEdit ||
DMMain->Foundation->State == dsInsert)
DMMain->Foundation->Post();
}
#include <vcl.h>
#pragma hdrstop
#include "TDMMain.h"
#include "TDMBase.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma link "RxQuery"
#pragma resource "*.dfm"
TDMMain *DMMain;
//---------------------------------------------------------------------------
__fastcall TDMMain::TDMMain(TComponent* Owner)
: TDataModule(Owner)
{
OperDataSet(true);
}
//---------------------------------------------------------------------------
bool __fastcall TDMMain::OperDataSet(bool value)
{
if(value)
OpenDateSet();
else
CloseDateSet();
}
//---------------------------------------------------------------------------
bool __fastcall TDMMain::OpenDateSet()
{
SGOODS->Open();
SVIDDEYATEL->Open();
Foundation->Open();
DeyatFnd->Open();
CostGoods->Open();
Information->Open();
qryFoundation->Open();
qryInformation->Open();
qryDeyatFnd->Open();
qryCostGoods->Open();
}
//---------------------------------------------------------------------------
bool __fastcall TDMMain::CloseDateSet()
{
qryInformation->Close();
qryDeyatFnd->Close();
qryCostGoods->Close();
qryFoundation->Close();
Foundation->Close();
DeyatFnd->Close();
CostGoods->Close();
Information->Close();
SGOODS->Close();
SVIDDEYATEL->Close();
}
//---------------------------------------------------------------------------
void __fastcall TDMMain::FoundationAfterPost(TDataSet *DataSet)
{
qryFoundation->Close();
qryFoundation->Open();
qryInformation->Close();
qryInformation->Open();
qryCostGoods->Close();
qryCostGoods->Open();
qryDeyatFnd->Close();
qryDeyatFnd->Open();
}
//---------------------------------------------------------------------------
void __fastcall TDMMain::PostFoundation()
{
//Foundation->Post();
}
void __fastcall TDMMain::CostGoodsBeforeInsert(TDataSet *DataSet)
{
//PostFoundation();
}
//---------------------------------------------------------------------------
void __fastcall TDMMain::SGOODSBeforePost(TDataSet *DataSet)
{
/*int ii = DataSet->FieldByName("id")->AsInteger;
Query1->Close();
Query1->ParamByName("id")->AsInteger = DataSet->FieldByName("id")->AsInteger;
Query1->Open();
AnsiString pp = Query1->FieldByName("col")->AsString;
bool b = Query1->Eof&&Query1->Bof;
if(Query1->FieldByName("col")->AsString!=0)
{
ShowMessage("Товар с таким идентификатором существует.");
Abort();
} */
}
//---------------------------------------------------------------------------
void __fastcall TDMMain::DataModuleDestroy(TObject *Sender)
{
OperDataSet(false);
}
1. Реферат на тему Время его герой и антигерой АС Грибоедов Горе от ума
2. Реферат на тему Основи правознавства
3. Диплом на тему Организация работы железной дороги
4. Реферат на тему Explain How Christian Teachings May Be Used
5. Курсовая на тему Роль психологических аспектов педагогического процесса в формировании будущего специалиста
6. Реферат на тему Bipolar Theory Essay Research Paper The phenomenon
7. Реферат Классические стили руководства
8. Контрольная работа Инвестиции предприятия
9. Реферат на тему Советская школа и педагогика в 1946 1985 гг 2
10. Реферат Оценка сильных и слабых сторон фирмы
