Проектирование информационного обеспечения
Идентификация и структурирование информационного пространства
На этапе предпроектного исследования предметной области были выделены функции, которые отображают детализацию нулевого процесса в соответствии с методологией DFD. Чтобы их реализовать необходимо, разработать базу данных, в которой будет храниться информация об информационных объектах предметной области.
Для описания сущностей используется язык инфологического моделирования.
СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n).
Независимые сущности:
1. Клиент (Номер счета, ФИО, Адрес, Телефон, Ааванс, Состояние счета,Код тарифа, Код фирмы).
Эта сущность отводится для хранения информации о клиентах.
2. Тариф (Код тарифа, Код фирмы,Название, Стоимость 1 минуты).
Эта сущность отводится для хранения информации о тарифах.
3. Тип Звонка (Номер типа звонка,Название типа звонка, Коэффициент Стоимости)
4. Фирма сотовой связи(Код фирмы,Название,Адрес)
5. Дилерский договор(Номер договора,Код фирмы,Телефон,Номер Контролирующей компании, Коэффициент стоимости)
Эта сущность отводится для хранения информации о звонках.
Схема базы данных
Структура данных предметной области может отображаться информационно-логической моделью. На основе этой модели легко создается реляционная база данных. Логическая модель данных определяет структуру базы данных в среде конкретной СУБД.
На рисунке 6 представлена модель предметной области.
Рис.4 Логическая модель БД «Сотовая связь»
После построения логической структуры БД проверяем на нарушение принципов нормализации, т.е. все ли ее атрибуты атомарные, а любой неключевой атрибут каждой таблицы:
· функционально зависят от полного первичного ключа, а не от его части, если ключ составной;
· не имеют функциональной зависимости от другого неключевого атрибута, то есть каждый неключевой атрибут не должен зависеть от ключа транзитивно (через другой промежуточный атрибут).
В данном случае, все атрибуты сущностей атомарные. Следовательно, все сущности находятся в 1НФ.
Сущности Клиент, Тип звонка и Фирма сотовой связи не имеют составного ключа. Неключевые поля, перечисленных сущностей, не имеют функциональной зависимости друг от друга. Поэтому они нормализованы.
На основании анализа данных можно задавать шаблоны, которые будут определять формат выводимых значений для отдельных полей.
Ограничение целостности
Целостность данных – это механизм поддержания соответствия базы данных предметной области.
В таблице 5 приводятся ограничения на домены созданных таблиц при вводе и редактировании данных для рассматриваемого примера.
Таблица 5 - Ограничение доменов
Таблица 5
Ограничения доменов
Имя домена | Допустимые значения | Разрешенные (вводимые) значения | |||
Тип | Размер | Диапазон возможных значений | Значения по умолчанию | ||
Клиент.Номер счета, Клиент.Код тарифа, Клиент.Код фирмы, Тариф.Код тарифа, Звонок.Номер звонка, Звонок.Номер Контролирующей компании, Звонок.номер Типа звонка, Звонок.Номер счета, Звонок. Код тарифа Звонок.Код фирмы, Тип.Номер типа звонка , ФирмаСС.Код Фирмы | int | - | 0-9999 | - | |
Звонок.Дата звонка | smalldatetime | 01.01.1958-31.12.2058 | - | ||
Клиент.ФИО, Клиент.Телефон Тариф.Название ФирмаСС.Название ФирмаСС.Адрес фирмы | char | - | - | ||
Клиент.Аванс, Клиент.Сост_Сч, Звонк.Цена | smallmoney | 0-30000 | |||
Ни одно из ключевых полей не может принимать значения NULL.
Расширенная реляционная модель данных (РМД) определяет еще два ограничения, которые должны выполняться в любой реляционной БД: целостность сущностей и целостность ссылок.
Для рассматриваемого примера такого типа ограничения приводятся в таблице 6.
Таблица 6
Ограничения уникальности на домены таблиц
№ n/n | Атрибут или группа атрибутов | Среди каких экземпляров, какой сущности |
Дил_Догов | всех экз. сущности «Дил_догов» | |
Тип_Зв.Номер_ТЗ | всех экз. сущности «Тип_Зв» | |
Тариф.Код_Т | всех экз. сущности «Тариф» | |
Фирма_СС.Код_Ф | всех экз. сущности «Фирма_СС» | |
Клиент.Номер_Сч | всех экз. сущности «Клиент» | |
Звонок.Номер_Зв | всех экз. сущности «Звонок» |
Следующие ограничения связаны с принятыми стратегиями поддержания целостности данных (таблица 8).
№ | Родительская сущность | Дочерняя сущность | Правило удаления | Правило обновления | Правило вставки |
Тариф | Звонок | каскадное | каскадное | ограничивающее | |
Тип_Звонка | Звонок | каскадное | каскадное | ограничивающее | |
Клиент | Звонок | каскадное | каскадное | ограничивающее | |
Фирма СС | Тариф | каскадное | каскадное | ограничивающее |
Таблица 7
Стратегии поддержания ссылочной целостности