Добавлен: 27.06.2023
Просмотров: 65
Скачиваний: 3
Инфологическая ᅟмодель ᅟ(ER-диаграмма)
В ᅟданной ᅟработе ᅟмодель ᅟбудет ᅟстроиться ᅟна ᅟоснове ᅟметода ᅟ«Сущность ᅟ– ᅟсвязь». ᅟЭтот ᅟметод ᅟоснован ᅟна ᅟER-диаграммах. ᅟДля ᅟясности ᅟдадим ᅟнекоторые ᅟосновные ᅟопределения.
-
- Сущность ᅟ– ᅟэто ᅟнекоторое ᅟмножество ᅟобъектов ᅟматериального ᅟи ᅟнематериального ᅟмира, ᅟинформация ᅟкоторых ᅟхранится ᅟв ᅟбазе ᅟданных.
- Ключ ᅟсущности ᅟ– ᅟнекоторое ᅟмножество ᅟатрибутов, ᅟслужащее ᅟдля ᅟопределения ᅟэкземпляров ᅟсущности.
В ᅟпервую ᅟочередь ᅟнеобходимо ᅟначать ᅟс ᅟописания ᅟобъектов ᅟбазы ᅟданных ᅟ(сущностей), ᅟопределения ᅟих ᅟатрибутов ᅟи ᅟустановки ᅟсвязей ᅟмежду ᅟсущностями.
Описание ᅟпредметной ᅟобласти
Консалтинговое ᅟагентство ᅟпредоставляет ᅟмаркетинговые ᅟуслуги ᅟ– ᅟконсультации ᅟв ᅟобласти ᅟаудита, ᅟэкспресс- ᅟанализа ᅟи ᅟбизнес-планирования ᅟдля ᅟпромышленных ᅟпредприятий.
Контракт ᅟподписывается ᅟкаждым ᅟклиентом ᅟпо ᅟкаждой ᅟуслуге. ᅟОн ᅟвключает: ᅟфамилию ᅟклиента, ᅟназвание ᅟкомпании ᅟклиента, ᅟвид ᅟуслуги, ᅟдату ᅟподписания, ᅟдату ᅟначала ᅟработ, ᅟдату ᅟзавершения ᅟработ, ᅟдату ᅟоплаты, ᅟсумму ᅟконтракта. ᅟСписок ᅟуслуг ᅟвключает: ᅟкод ᅟуслуги, ᅟвид ᅟуслуги. ᅟДанные ᅟна ᅟклиентов ᅟвключают: ᅟимя ᅟклиента, ᅟфамилию ᅟклиента, ᅟназвание ᅟкомпании ᅟклиента, ᅟгород, ᅟадрес, ᅟномер ᅟтелефона. ᅟВ ᅟконсалтинговом ᅟагентстве ᅟназначается ᅟменеджер ᅟпроекта ᅟпо ᅟкаждому ᅟконтракту. ᅟДанные ᅟна ᅟменеджеров ᅟпроекта ᅟсодержат: ᅟфамилию ᅟи ᅟимя ᅟработника, ᅟномер ᅟтелефона.
Запросы ᅟи ᅟотчеты ᅟдолжны ᅟбыть ᅟсоставлены, ᅟчтобы ᅟпредоставлять ᅟпользователю ᅟбазы ᅟданных ᅟследующую ᅟинформацию:
-
- список ᅟклиентов, ᅟсгруппированный ᅟпо ᅟгородам;
- отчет ᅟпо ᅟконтрактам;
- список ᅟконтрактов ᅟпо ᅟотдельной ᅟуслуге;
- список ᅟконтрактов, ᅟсгруппированный ᅟпо ᅟвиду ᅟуслуги ᅟза ᅟпрошедший ᅟгод;
- три ᅟсамых ᅟважных ᅟклиента ᅟ(принесших ᅟнаибольшую ᅟприбыль);
- список ᅟработников, ᅟотсортированный ᅟв ᅟобратном ᅟпорядке ᅟв ᅟзависимости
от ᅟвеличины ᅟсуммы ᅟконтрактов;
-
- ежемесячная ᅟсумма ᅟконтрактов ᅟна ᅟуслуги ᅟкаждого ᅟвида;
- годовой ᅟотчет ᅟпо ᅟсумме, ᅟполученной ᅟза ᅟоказанные ᅟуслуги;
- запрос ᅟна ᅟсоздание ᅟархивной ᅟтаблицы ᅟи ᅟзапрос ᅟна ᅟисключение ᅟданных ᅟиз ᅟосновной ᅟтаблицы ᅟконтрактов, ᅟвыполненных ᅟ3 ᅟгода ᅟназад ᅟи ᅟболее.
Перечислим ᅟсущности:
-
- «Данные ᅟна ᅟклиентов», ᅟ
- «Контракты», ᅟ
- «Список ᅟуслуг», ᅟ
- «Данные ᅟна ᅟменеджеров».
Определим ᅟатрибуты ᅟсущности ᅟ– ᅟэто ᅟпоименованная ᅟхарактеристика ᅟсущности.
Таблица ᅟ4. ᅟАтрибуты ᅟсущности ᅟДанные ᅟна ᅟклиентов
|
Код ᅟклиента |
Числовой |
|
Имя ᅟклиента |
Текстовый |
|
Фамилия ᅟклиента |
Текстовый |
|
Компания |
Текстовый |
|
Город |
Текстовый |
|
Адрес |
Текстовый |
|
Телефон |
Числовой |
Таблица ᅟ5. ᅟАтрибуты ᅟсущности ᅟКонтракты
|
Код ᅟконтракта |
Числовой |
|
Фамилия ᅟклиента |
Текстовый |
|
Компания ᅟклиента |
Текстовый |
|
Вид ᅟуслуги |
Текстовый |
|
Дата ᅟподписания |
Дата |
|
Дата ᅟначала ᅟработ |
Дата |
|
Дата ᅟзавершения ᅟработ |
Дата |
|
Дата ᅟоплаты |
Дата |
|
Сумма ᅟконтракта |
Числовой |
Таблица ᅟ6. ᅟАтрибуты ᅟсущности ᅟСписок ᅟуслуг
|
Код ᅟуслуги |
Числовой |
|
Вид ᅟуслуги |
Текстовый |
Таблица ᅟ7. ᅟАтрибуты ᅟсущности ᅟДанные ᅟна ᅟменеджеров
|
Код ᅟменеджера |
Числовой |
|
Фамилия ᅟ |
Текстовый |
|
Имя ᅟ |
Текстовый |
|
Телефон |
Числовой |
2.2. ᅟСоздание ᅟсвязей ᅟмежду ᅟсущностями
Дадим ᅟопределение:
-
- Связь ᅟмежду ᅟсущностями ᅟ– ᅟэто ᅟассоциация ᅟмежду ᅟдвумя ᅟи ᅟболее ᅟсущностями.
- Класс ᅟпринадлежности ᅟэкземпляров ᅟсущности: ᅟговорят, ᅟчто ᅟсущность ᅟобладает ᅟобязательным ᅟклассом ᅟпринадлежности, ᅟесли ᅟвсе ᅟэкземпляры ᅟпервой ᅟсущности ᅟ(или ᅟвторой) ᅟсвязаны ᅟхотя ᅟбы ᅟс ᅟодним ᅟэкземпляром ᅟвторой ᅟ(или ᅟпервой) ᅟсущности.
Класс ᅟпринадлежности ᅟможет ᅟбыть ᅟобязательным ᅟили ᅟнеобязательным.
0 ᅟ(необязательный) ᅟ– ᅟесли ᅟкаждый ᅟэкземпляр ᅟсущности ᅟне ᅟсвязан ᅟни ᅟс ᅟодним ᅟэкземпляром ᅟдругой ᅟсущности;
1 ᅟ(обязательный) ᅟ– ᅟесли ᅟкаждый ᅟэкземпляр ᅟсущности ᅟсвязан ᅟхотя ᅟбы ᅟс ᅟодним ᅟэкземпляром ᅟдругой ᅟсущности.
В ᅟнашем ᅟслучае ᅟсущности ᅟ«Контракты» ᅟи ᅟ«Данные ᅟна ᅟклиентов» ᅟимеют ᅟвид ᅟсвязи ᅟ«один-к-одному» ᅟс ᅟклассом ᅟпринадлежности ᅟ1, ᅟт.е. ᅟконтракт ᅟподписывается ᅟкаждым ᅟклиентом ᅟпо ᅟкаждой ᅟуслуге. ᅟСущности ᅟ«Контракты» ᅟи ᅟ«Список ᅟуслуг» ᅟимеют ᅟвид ᅟсвязи ᅟ«один-ко-многим» ᅟс ᅟклассом ᅟпринадлежности ᅟ0, ᅟт.е. ᅟодна ᅟуслуга ᅟможет ᅟфигурировать ᅟв ᅟнескольких ᅟконтрактах, ᅟно ᅟесть ᅟуслуги, ᅟпо ᅟкоторым ᅟне ᅟбыл ᅟподписан ᅟконтракт. ᅟСущности ᅟ«Контракты» ᅟи ᅟ«Данные ᅟна ᅟменеджеров» ᅟтакже ᅟимеют ᅟвид ᅟсвязи ᅟ«один-ко-многим» ᅟс ᅟклассом ᅟпринадлежности ᅟ0, ᅟт.е. ᅟодин ᅟменеджер ᅟможет ᅟвести ᅟнесколько ᅟконтрактов ᅟили ᅟни ᅟодного.
Преобразуем ᅟсущность ᅟв ᅟотношение ᅟили ᅟнабор ᅟотношений, ᅟмежду ᅟкоторыми ᅟустановим ᅟсвязи. ᅟОтношение ᅟпредставляет ᅟсобой ᅟтаблицу. ᅟТаблица ᅟимеет ᅟстолбцы ᅟ(поля) ᅟи ᅟстроки ᅟ(записи). ᅟ
Преобразования ᅟсущностей ᅟв ᅟсовокупность ᅟотношений: ᅟ
1. ᅟДля ᅟтех ᅟсущностей, ᅟкоторые ᅟимеют ᅟкласс ᅟпринадлежности ᅟ1, ᅟсоздадим ᅟодно ᅟотношение ᅟс ᅟполями, ᅟсоответствующими ᅟатрибутам ᅟсущностей, ᅟа ᅟдля ᅟсущностей, ᅟкоторые ᅟимеют ᅟнулевой ᅟкласс ᅟпринадлежности, ᅟсоздадим ᅟтри ᅟотношения.
2. ᅟДля ᅟкаждой ᅟсущности, ᅟимеющей ᅟсвязь ᅟс ᅟдругими ᅟсущностями ᅟкак ᅟ«один-ко-многим» ᅟили ᅟ«один-к-одному», ᅟукажем ᅟодин ᅟстолбец ᅟв ᅟкачестве ᅟпервичного ᅟключа.
3. ᅟДля ᅟкаждой ᅟсущности, ᅟкоторая ᅟвыступает ᅟкак ᅟ«многие-к-одному» ᅟво ᅟвзаимоотношениях ᅟхотя ᅟбы ᅟс ᅟодной ᅟсущностью, ᅟукажем ᅟв ᅟкачестве ᅟвнешних ᅟключей ᅟпервичные ᅟключи ᅟкаждой ᅟиз ᅟродительских ᅟсущностей.
4. ᅟЗададим ᅟпервичный ᅟключ ᅟдля ᅟкаждой ᅟсущности, ᅟвыступающей ᅟво ᅟвзаимоотношениях ᅟкак ᅟ«многие-к-одному».
Выполним ᅟвыше ᅟперечисленные ᅟдействия ᅟдля ᅟданного ᅟпроекта.
1. ᅟСоздадим ᅟчетыре ᅟтаблицы ᅟс ᅟполями, ᅟсоответствующими ᅟатрибутам ᅟсущностей.
2. ᅟСоздадим ᅟеще ᅟдве ᅟтаблицы ᅟдля ᅟсущностей ᅟс ᅟклассом ᅟпринадлежности ᅟ0 ᅟ(«Контракты» ᅟ- ᅟ«Список ᅟуслуг» ᅟи ᅟ«Контракты» ᅟ- ᅟ«Данные ᅟна ᅟменеджеров»).
3. ᅟЗададим ᅟпервичные ᅟключи ᅟдля ᅟтаблиц ᅟ«Данные ᅟна ᅟклиентов» ᅟи ᅟ«Контракты», ᅟвыступающих ᅟв ᅟсвязи ᅟ«один-к-одному», ᅟи ᅟдля ᅟтаблиц ᅟ«Список ᅟуслуг» ᅟи ᅟ«Данные ᅟна ᅟменеджеров», ᅟвыступающих ᅟв ᅟсвязи ᅟ«один-ко-многим» ᅟс ᅟтаблицей ᅟ«Контракты». ᅟ
- Первичный ᅟключ ᅟ– ᅟэто ᅟполе ᅟили ᅟминимальный ᅟнабор ᅟполей,
однозначно ᅟопределяющий ᅟкаждую ᅟстроку ᅟтаблицы. ᅟ
Первичные ᅟключи ᅟслужат ᅟидентификаторами ᅟкортежей ᅟ(строк ᅟв ᅟтаблице), ᅟдля ᅟускорения ᅟработы ᅟсо ᅟстроками ᅟтаблицы, ᅟсвязывания ᅟтаблиц.
Таблица ᅟ«Данные ᅟна ᅟклиентов» ᅟимеет ᅟв ᅟсвоем ᅟсоставе ᅟуникальное ᅟдля ᅟкаждой ᅟстроки ᅟполе ᅟ– ᅟКод ᅟклиента. ᅟВ ᅟтаблице ᅟ«Контракты» ᅟв ᅟкачестве ᅟпервичного ᅟключа ᅟтакже ᅟвыступает ᅟполе ᅟКод ᅟконтракта. ᅟВ ᅟтаблице ᅟ«Список ᅟуслуг» ᅟпервичным ᅟключом ᅟбудет ᅟполе ᅟКод ᅟуслуги, ᅟа ᅟв ᅟтаблице ᅟ«Данные ᅟна ᅟменеджеров» ᅟ- ᅟКод ᅟменеджера.
Сущности ᅟ«Контракты», ᅟ«Список ᅟуслуг», ᅟ«Данные ᅟна ᅟменеджеров» ᅟимеют ᅟсвязь ᅟ«один-ко-многим», ᅟпоэтому ᅟв ᅟкачестве ᅟвнешних ᅟключей, ᅟсвязывающих ᅟтаблицы, ᅟбудут ᅟвыступать ᅟпервичные ᅟключи ᅟкаждой ᅟтаблицы ᅟсущности. ᅟПоле ᅟподчиненной ᅟтаблицы, ᅟпо ᅟкоторому ᅟосуществляется ᅟсвязь, ᅟназывается ᅟвнешним ᅟключом ᅟглавной ᅟтаблицы.
Физическая ᅟмодель
Главными ᅟвопросами ᅟфизического ᅟпроектирования ᅟявляются ᅟоптимизация ᅟвремени ᅟвыполнения ᅟосновных ᅟзапросов ᅟк ᅟбазе ᅟданных ᅟи ᅟобеспечение ᅟбезопасности ᅟданных.
Для ᅟповышения ᅟпроизводительности ᅟреляционные ᅟСУБД ᅟиспользуют ᅟспециальные ᅟобъекты, ᅟназываемые ᅟиндексами. ᅟПри ᅟописании ᅟструктуры ᅟтаблицы ᅟзадаются ᅟиндексы ᅟс ᅟпомощью ᅟсвойства ᅟполей, ᅟназываемого ᅟиндексированным ᅟполем. ᅟИндексированное ᅟполе ᅟможет ᅟпринимать ᅟтри ᅟзначения:
1. ᅟнеиндексированное;
2. ᅟдопускаются ᅟсовпадения;
3. ᅟсовпадения ᅟне ᅟдопускаются.
Индекс ᅟсодержит ᅟнабор ᅟзаписей ᅟиз ᅟдвух ᅟэлементов: ᅟ{значение ᅟключевого ᅟполя; ᅟуказатель ᅟна ᅟсоответствующую ᅟзапись ᅟв ᅟтаблице}. ᅟИндекс ᅟупорядочен ᅟпо ᅟзначению ᅟключевого ᅟполя, ᅟчто ᅟпозволяет ᅟсистеме ᅟбыстро ᅟнаходить ᅟнужные ᅟзначения. ᅟВ ᅟреляционных ᅟСУБД ᅟтаблицы ᅟвсегда ᅟиндексируются ᅟпо ᅟполю/полям ᅟпервичного ᅟключа. ᅟВ ᅟAccess ᅟиндексированные ᅟполя ᅟне ᅟобязательно ᅟключевые. ᅟСчитается ᅟнормой, ᅟесли ᅟтаблица ᅟимеет ᅟхотя ᅟбы ᅟодно ᅟключевое ᅟполе.
Обычно ᅟиндексы ᅟиспользуют ᅟв ᅟбазах ᅟданных, ᅟбольших ᅟпо ᅟобъему, ᅟпоэтому ᅟиндексы ᅟможно ᅟне ᅟиспользовать. ᅟСоздадим ᅟиндексированные ᅟполя ᅟтолько ᅟпо ᅟполю ᅟпервичного ᅟключа ᅟ(таблица ᅟ8). ᅟ
Таблица ᅟ8. ᅟИндексированные ᅟполя
|
Таблица |
Индексированное ᅟполе |
|
Данные ᅟна ᅟклиентов |
Код ᅟклиента |
|
Контракты |
Код ᅟконтракта |
|
Список ᅟуслуг |
Код ᅟуслуги |
|
Данные ᅟна ᅟменеджеров |
Код ᅟменеджера |
ГЛАВА ᅟ3. ᅟРЕАЛИЗАЦИЯ ᅟПРОЕКТИРОВАНИЯ ᅟСИСТЕМЫ ᅟАВТОМАТИЗИРОВАННОЙ ᅟОБРАБОТКИ ᅟЭКОНОМИЧЕСКОЙ ᅟИНФОРМАЦИИ
3.1. ᅟСоздание ᅟтаблиц ᅟи ᅟсхем ᅟданных
Создадим ᅟструктуру ᅟвсех ᅟтаблиц ᅟв ᅟрежиме ᅟКонструктора ᅟтаблиц. ᅟНа ᅟрис. ᅟ1 ᅟпредставлено ᅟокно ᅟконструктора ᅟс ᅟописанием ᅟтаблицы ᅟДанные ᅟна ᅟклиентов. ᅟПосле ᅟсоздания ᅟполей ᅟтаблицы ᅟв ᅟсоответствии ᅟможно ᅟпросмотреть ᅟсозданные ᅟсистемой ᅟиндексы ᅟ(рис. ᅟ5). ᅟТ.к. ᅟнаша ᅟбаза ᅟне ᅟбольшая, ᅟто ᅟне ᅟбудем ᅟсоздавать ᅟиндексы ᅟдля ᅟвсех ᅟполей.
Рис. ᅟ5. ᅟОкно ᅟконструктора
Рис. ᅟ6. ᅟОкно ᅟиндексы
Аналогично ᅟсоздадим ᅟостальные ᅟтаблицы. ᅟ
Рис. ᅟ7. ᅟДанные ᅟтаблицы ᅟ«Данные ᅟна ᅟклиентов»
Рис. ᅟ8. ᅟДанные ᅟтаблицы ᅟ«Контракты»
Рис. ᅟ9. ᅟДанные ᅟтаблицы ᅟ«Список ᅟуслуг ᅟ»
Рис. ᅟ10. ᅟДанные ᅟтаблицы ᅟ«Данные ᅟна ᅟменеджеров»
ᅟСоздание ᅟсвязей ᅟмежду ᅟтаблицами
Покажем ᅟсвязи ᅟпо ᅟключевым ᅟполям, ᅟобеспечивая ᅟцелостность ᅟданных, ᅟа ᅟтакже ᅟкаскадное ᅟобновление/удалении ᅟсвязанных ᅟполей. ᅟТаким ᅟобразом, ᅟполучим ᅟследующую ᅟсхему ᅟданных, ᅟпредставленную ᅟна ᅟрис. ᅟ11.
Рис. ᅟ11. ᅟСхема ᅟданных
На ᅟрис. ᅟ12. ᅟотображено ᅟокно ᅟизменения ᅟсвязей:
Рис. ᅟ12. ᅟИзменение ᅟсвязей
Разработка ᅟзапросов ᅟк ᅟбазе ᅟданных
Основным ᅟвидом ᅟиспользования ᅟбазы ᅟданных ᅟявляется ᅟпоиск ᅟнужной ᅟинформации ᅟдля ᅟвывода ᅟили ᅟпоследующей ᅟобработки. ᅟПростейшими ᅟоперациями ᅟпоиска ᅟявляются ᅟфильтрация ᅟи ᅟсортировка ᅟзаписей ᅟв ᅟодной ᅟтаблице. ᅟОднако ᅟнаиболее ᅟобщий ᅟи ᅟгибкий ᅟпуть ᅟ– ᅟэто ᅟпостроение ᅟзапросов ᅟк ᅟбазе ᅟданных. ᅟБольшинство ᅟзапросов ᅟсоздается ᅟсразу ᅟна ᅟэтапе ᅟсоздания ᅟбазы ᅟданных, ᅟтак ᅟкак ᅟэто ᅟрегулярно ᅟполучаемая ᅟинформация, ᅟдля ᅟполучения ᅟкоторой ᅟи ᅟсоздавалась ᅟбаза ᅟданных. ᅟВ ᅟто ᅟже ᅟвремя ᅟна ᅟлюбом ᅟэтапе ᅟэксплуатации ᅟбазы ᅟданных ᅟмогут ᅟбыть ᅟпостроены ᅟновые ᅟзапросы ᅟдля ᅟреализации ᅟновой ᅟфункции.