Описание предметной области: «АТС. Формирование квитанций на оплату услуг связи»

Содержание:

1. Нормализация отношений при проектировании баз данных. Первая нормальная форма…………………………………………………………………………………...3-5

2. Описание предметной области: «АТС. Формирование квитанций на оплату услуг связи»……………………………………………………….........................................6-14

2.1.Исследование предметной области……………………………………….6-7

2.2. Построение концептуальной модели предметной области…………….7-8

2.3. Построение логической модели предметной области…….........................9

2.4. Построение физической модели предметной области……………….10-11

2.5. Запросы………………………………………………………......................12

2.6. Отчеты……………………...……………………………………………13-14

3. Список литературы………………………………………………………………….15

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

-2-

 

1. Нормализация отношений при проектировании баз данных. Первая нормальная форма.

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

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

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

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

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

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

-3-

принципами  здравого смысла, которыми руководствуется  в своём сознании зрелый проектировщик, то есть принципы нормализации — это формализованный здравый смысл. Между тем, идентифицировать и формализовать принципы здравого смысла — весьма трудная задача, и успех в её решении является существенным достижением.

Первая  нормальная форма (1NF) — базовая нормальная форма отношения в реляционной модели данных.

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

В реляционной модели отношение  всегда находится в первой нормальной форме по определению понятия отношение.

Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1NF. В соответствии с определением К. Дж. Дейта для такого случая, таблица нормализована (эквивалентно — находится в первой нормальной форме) тогда и только тогда, когда она является прямым и верным представлением некоторого отношения. Конкретнее, рассматриваемая таблица должна удовлетворять следующим пяти условиям:

1. Нет упорядочивания строк сверху-вниз (другими словами, порядок строк не несет в себе никакой информации).
2. Нет упорядочивания столбцов слева-направо (другими словами, порядок столбцов не несет в себе никакой информации).
3. Нет повторяющихся строк.
4. Каждое пересечение строки и столбца содержит ровно одно значение из соответствующего домена (и больше ничего).
5. Все столбцы являются обычными.

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

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

 

СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (Н_СОТР, ФАМ, Н_ОТД, ТЕЛ, Н_ПРО, ПРОЕКТ, Н_ЗАДАН)

где

Н_СОТР - табельный номер сотрудника

ФАМ - фамилия сотрудника

Н_ОТД - номер отдела, в котором числится сотрудник

ТЕЛ - телефон сотрудника

-4-

 

Н_ПРО - номер проекта, над которым работает сотрудник

ПРОЕКТ - наименование проекта, над которым работает сотрудник

Н_ЗАДАН - номер задания, над которым работает сотрудник

 

Т.к. каждый сотрудник  в каждом проекте выполняет ровно  одно задание, то в качестве потенциального первичного ключа отношения необходимо взять пару атрибутов {Н_СОТР, Н_ПРО}.

В текущий момент состояние предметной области отражается следующими фактами(выделены ключевые атрибуты):

 

 

 

Н_СОТР	ФАМ	Н_ОТД	ТЕЛ	Н_ПРО	ПРОЕКТ	Н_ЗАДАН
1	Иванов	1	11-22-33	1	Космос	1
1	Иванов	1	11-22-33	2	Климат	1
2	Петров	1	11-22-33	1	Космос	2
3	Сидоров	2	33-22-11	1	Космос	3
3	Сидоров	2	33-22-11	2	Климат	2

Таблица 1 Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ

Недостатки  этого отношения:

• Невозможность вставить сотрудника, который не принимает участие ни в одном проекте, аналогично невозможно вставить проект, если им пока никто не занимается – аномалия вставки. Причина этой аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).
• Изменение информации о фамилии, названии проекта, телефоне приводит к необходимости изменять информацию в нескольких местах – аномалия обновления. Причина этой аномалии –избыточность хранения информации (повтор фамилий, названий проектов, телефонов).
• При удалении информации, например о проекте Космос, будет утеряна информация о Петрове, т.к. он работает только в том проекте – аномалия удаления.  Причина этой аномалии - хранение в одном отношении разнородной информации. Вывод - Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ находится в 1НФ, но при этом, как было показано выше, логическая модель данных не соответствует модели предметной области.

-5-

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

 

2. Описание предметной области: «АТС. Формирование квитанций на оплату услуг связи».

 

2.1. Исследование предметной области

Наименование предприятия:  Отделение АТС

Цель разработки информационной системы: Автоматизация учета принимаемых звонков, сведение об клиенте.

Точка зрения: Оператор

Пользователи: зав. отделением АТС, оператор АТС.

Перечень бизнес-процессов:

1. Ведение тарифных  справочников: по пунктам назначения  и категориям квитанций.

2.Прием квитанций:

• Каждой квитанции присваивается уникальный номер;
• Данные звонящего заносятся в специальный справочник;
• Производится расчет стоимости звонка по формуле: тариф за одну минуту * продолжительность.
• Рассчитывается стоимость разговора.

3.Формирование  отчетов. В конце отчетного  периода оператор готовит следующие  отчеты для заведующего отделением:

• О продолжительности разговоров за месяц;
• о количестве квитанций за отчетный период;
• О выручке.

 

-6-

Описание регламента для некоторых  процессов:

• Расчет стоимости производится строго по тарифам, указанным в справочнике.

Обновление  тарифов производится только на основании  руководящих документов Центрального отделения АТС.

• Отчетный период составляет 30 дней.

Перечень процессов, для поддержки  которых создается ИС (база данных):

• Ведение тарифных справочников.
• Регистрация звонков.
• Формирование квитанций на оплату.
• Формирование отчетов.

 

2.2. Построение концептуальной модели предметной области

Перечень выявленных сущностей:

• Плательщик;
• МТР;
• Регион;
• Квитанция;
• Состав платежа.

Плательщик

S - Код плательщика

S - ФИО

D - Адрес

D – Телефон

МТР

S - Номер МТР

S - Код региона

D – Продолжительность

-7-

 

D - Дата

S - Код плательщика

 

Регион

S - Код региона

S - Название

D - Тариф за одну минуту

 

Квитанция

S - Номер квитанции

S - Код плательщика

S - Дата квитанции

 

Состав платежа

D - Номер

D - Номер квитанции

D - Номер МТР

 

 

 

 

 

 

 

-8-

 

2.3. Построение логической модели предметной области

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

-9-

 

2.4. Построение физической модели предметной области

 

Плательщик         Таблица 1

Название  поля	Ключ	Тип данных	Размер
Код плательщика	(РК)	числовой	целое
ФИО		текстовый	3
Адрес		текстовый	целое
Телефон		текстовый	3

 

      МТР          Таблица 2

Название  поля	Ключ	Тип данных	Размер
Номер МТР	(РК)	числовой	целое
Код региона	(FK)	числовой	целое
Продолжительность		числовой	целое
Дата		Дата/Время
Код плательщика	(FK)	числовой	целое