Проектирование и разработка информационной системы «Учет клиентов регионального информационного центра компании «КонсультантПлюс»

Атрибут – свойство сущности (заголовок столбца таблицы). Перечислим атрибуты вышеназванных сущностей:

Организации – клиенты (Код организации, Наименование организации, Адрес (почтовый), Адрес (юридический), ИНН, КПП, Расчетный счет, Банк, Постоянный клиент, Размер организации, Вид деятельности, Телефон/факс,

e-mail, Контактное лицо, Должность контактного лица, Примечание).

Договора (№ договора, Дата договора, Код организации, Срок договора, Код сотрудника).

Расшифровка договора (№ договора, Код системы, Количество).

Системы (Код экземпляра системы, Код раздела, Наименование экземпляра системы, Признак системы, Номер дистрибутива, Стоимость (в мес.), Периодичность обновления, Код номенклатуры услуг).

Разделы (Код раздела, Наименование раздела, Примечание).

Заявки (№ заявки, Дата заявки, Вид обучения, Дата обучения, Вид занятий, Код организации, Количество человек, Стоимость (1 чел.), Примечание).

Подписка (Код подписки, Дата Подписки, Наименование подписки, ID расшифровка, Код услуги, Код организации).

Расшифровка подписи (ID расшифровка, Срок подписки, Стоимость подписки).

Номенклатура услуг (Код номенклатуры, Наименование, Примечание).

Сотрудники (Код сотрудника, Фамилия, Имя, Отчество, Код подразделения, Должность).

Подразделения (Код подразделения, Наименование подразделения).

 

2.3 Датологическое моделирование системы

 

Построим датологическую модель будущей базы данных «Учет клиентов ООО «фирма Байт».

База данных представляет собой хранилище связанных между собой данных. Данные должны быть структурированы для возможности быстрого к ним доступа и обработки.

Структурирование – введение соглашений о способах представления данных. Например, обычный текст не содержит структурированные данные, а телефонный справочник структурирован.

База данных – поименованная совокупность структурированных данных, относящихся к определенной предметной области. Создание базы данных, ее поддержка, сопровождение осуществляются с помощью специального программного средства – системы управления базами данных.

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

Работа с базой данных делится на три этапа:

1. Проектирование.
2. Программная эксплуатация.
3. Эксплуатация.

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

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

Затем необходимо провести этап создания базы данных на компьютере, а именно:  составить структуры таблиц и ввести их в компьютер; разработать запросы для отбора данных, отчеты для печати, создать экранные формы работы с данными; спланировать порядок ведения и поддержание базы данных в рабочем состоянии.

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

В целом, разработка базы данных включает следующие этапы:

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

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

Таблицы баз данных состоят из столбцов – полей и строк – записей. Каждое поле таблицы содержит однородные данные, а каждая запись отражает совокупность данных, относящихся к одному конкретному объекту (например, таблица Организации – клиенты, Сотрудники).

Реляционная таблица представляется двумерным массивом и обладает следующими свойствами:

– каждая ячейка таблицы содержит один элемент данных;

– все ячейки одного столбца содержат одинаковый тип данных определенной длины;

– каждый столбец имеет уникальное имя;

– каждая строка таблицы хранит сведения, относящихся к одному объекту;

– порядок следования строк и столбцов может быть произвольным;

– одинаковые строки в таблице отсутствуют.

Для идентификации записей в таблице должно быть хотя бы одно поле, которое называется ключевым. Это поле используется для связи разных таблиц. Поле, каждое значение которого однозначно определяет соответствующую запись, именуется простым ключом. Так, в таблице «Организации–клиенты» ключевым полем служит поле «Код организации», в таблице «Сотрудники» - «Код сотрудника». Для связи реляционных таблиц ключ первой таблицы, называемый первичным, может вводиться в структуру второй таблицы, а ключ второй таблицы (внешний) может вводиться в первую таблицу.  

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

Приведем наши отношения к третьей нормальной форме.

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

Вторая НФ: Таблица находится во второй нормальной форме, если она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

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

Отношения, представленные в данной БД приведены к третьей нормальной форме.

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

База данных, состоящая из нескольких таблиц, должна иметь межтабличные связи, обеспечивающие целостность всех данных базы и автоматизацию задач обслуживания. Существуют три типа связей между таблицами базы данных:

1. Связь один к одному (1:1) между таблицами предполагает, что в каждый момент времени одной записи в первой таблице соответствует единственная запись во второй таблице, и наоборот. Например, каждая запись в таблице «Организация – клиенты» может соответствовать единственной записи в другой таблице, включающей поле «Код организации».
2. Связь один ко многим (1:М) между таблицами предполагает, что в каждый момент времени одной записи в первой таблице соответствует несколько записей во второй таблице. Например, каждая запись в таблице «Организация – клиенты» может соответствовать нескольким записям другой таблицы, включающей поле, содержащие «Код организации».
3. Связь многие ко многим (М:М). Такая связь между таблицами предполагает, что в каждый момент времени одной записи в первой таблице соответствует несколько записей во второй таблице, и одной записи во второй таблице соответствует несколько записей в первой таблице. Связь реализуется посредством создания третьей таблицы, в которой одно поле совпадает с ключевым полем первой таблицы, а второе – с ключевым полем второй таблицы.

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

Так как  первичный ключ – это некое поле (столбец) или группа полей таблицы базы данных, значение которого (или комбинация значений которых), используется в качестве однозначного уникального идентификатора записи (строки) этой таблицы, например, в таблице «Подразделения» в качестве первичного ключа целесообразно определить «Код подразделения», в таблице «Организации-клиенты» - поле «Код организации», в таблице «Сотрудники»  - поле «Код сотрудника», в таблице «Договора» - поле «№ договора», в таблице «Подписка» - «Код подписки», в таблице «Расшифровка подписки» - поле «ID расшифровкa», в таблице «Заявки» - поле «Код заявки», в таблице «Номенклатура услуг» - «Код номенклатуры», в таблице «Системы» - поле «Код экземляра системы», в таблице «Разделы» - поле «Код раздела».

Таким образом, получим следующую схему данных:

 

Рисунок 2.2 Схема данных

В разрабатываемой БД сущность «Код сотрудника» будет являться ключом для атрибута «Организации-клиенты», сущность «№ договора» - ключ для атрибута «Договора».

Для атрибута «Расшифровка договора» ключом будут являться две сущности: «№ договора» и «Код системы», то есть ключ будет составным.

Структура необходимых данных представлена ниже:

 

Таблица 2.1 Логическая структура основной таблицы

«Организация - клиенты»

Название поля	Тип данных	Длина	Тип поля
Код организации	Счетчик		Ключевое
Наименование организации	Текстовый	50
Адрес (почтовый)	Текстовый	70
Адрес (юридический)	Текстовый	70
ИНН	Числовой	Длинное целое
КПП	Числовой	Длинное целое
Расчетный счет	Текстовый	20
Банк	Текстовый	45
Постоянный клиент	Логический
Размер организации	Текстовый	15	Мастер подстановок
Вид деятельности	Текстовый	70
Телефон / факс	Текстовый	30
e-mail	Текстовый	25
Контактное лицо	Текстовый	40
Должность контактного лица	Текстовый	15
Примечание	Текстовый	30