Разработка базы данных экономической информационной системы для обработки информации по списанию основных средств

Имя атрибута	Описание
Код подразделения	Первичный ключ
Название подразделения	Название подразделения
Инвентарный номер	Инвентарный номер ОС
Наименование	Наименование ОС
Дата принятия к бухучету	Дата принятия к бухучету

 

 

Таблица 2 –Атрибуты сущности «Акты списания»

Имя атрибута	Описание
Номер акта списания	Первичный ключ
Дата	Дата подписания акта о списании
Описание	Дополнительная информация

 

 

Таблица 3 –Атрибуты сущности «Списанные основные средства»

Имя атрибута	Описание
Номер акта списания	Номер акта списания
Инвентарный номер	Первичный ключ
Наименование	Наименование ОС
Количество капитальных  ремонтов	Количество капитальных  ремонтов
Содержание драгоценных металлов	Количество капитальных  ремонтов
Первоначальная стоимость	Первоночальная стоимость  ОС
Сумма начисленной амортизации	Сумма начисленной амортизации  ОС
Остаточная стоимость	Остаточная стоимость  ОС
Причина списания	Причина списания ОС

Таблица 4 –Атрибуты сущности «Подразделения»

Имя атрибута	Описание
Код подразделения	Первичный ключ
Название подразделения	Название подразделения
Адрес	Адрес подразделения
Телефон	Телефон подразделения
Контактное лицо	Представитель подразделения

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.1 Построение ERD-диаграммы

 

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

• диаграмма зависимостей сущностей (ERD-диаграмма);
• модель основанная на ключах (Key Based, KB);
• полностью определенная модель (FA).

Первым шагом при  создании логической модели является создание ERD-диаграммы – модели данных высокого уровня, описывающей широкие области бизнеса.

ERD состоит из трех  основных блоков: сущностей, атрибутов  и связей. Если рассматривать  диаграмму как некий графический  язык, то можно заметить, что объекты  являются существительными, атрибуты  – прилагательными, а зависимости – глаголами этого языка. Построение модели данных в ERwin заключается в нахождении правильного набора существительных, глаголов и прилагательных и в правильном их сочетание. На рисунке 1 представлена ERD-диаграмма логической модели.

Рисунок 1 – Логическая модель базы данных

 

Основная задача ERD-диаграммы – оценить, какие требования к бизнес-информации будут достаточными для обеспечения нужд планирования разработки информационной системы. Эти модели не очень подробны (включены только основные сущности), атрибуты тоже слабо детализируются.

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

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

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

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

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

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

Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Key). ERwin позволяет выделить атрибуты альтернативных ключей. В дальнейшем, по умолчанию, при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).

Следующим этапом при  построении логической модели является определение ключевых атрибутов и типов атрибутов. Типы атрибутов представлены в таблицах 5, 6, 7, 8.

 

Таблица 5 –Типы атрибутов сущности «Основные средства на балансе предприятия»

Имя атрибута	Описание	Размер поля
Код подразделения	Numeric	10
Название подразделения	Character	20
Инвентарный номер	Numeric	10
Наименование	Character	20
Дата принятия к бухучету	Date

 

Таблица 6 –Типы атрибутов сущности «Акты списания»

Имя атрибута	Описание	Размер поля
Номер акта списания	Numeric	10
Дата	Date
Описание	Character	25

Таблица 7 –Типы атрибутов сущности «Списанные основные средства»

Имя атрибута	Описание	Размер поля
Номер акта списания	Numeric	10
Инвентарный номер	Numeric	10
Наименование	Character	20
Количество капитальных  ремонтов	Numeric	2
Содержание драгоценных  металлов	Logical
Первоначальная стоимость	Numeric	8,2
Сумма начисленной амортизации	Numeric	8,2
Остаточная стоимость	Numeric	8,2
Причина списания	Character	25

 

 

Таблица 8 –Типы атрибутов  сущности «Подразделения»

Имя атрибута	Описание	Размер поля
Код подразделения	Numeric	10
Название подразделения	Character	20
Адрес	Character	20
Телефон	Character	15
Контактное лицо	Character	20

 

 

 

 

 

 

 

 

 

 

3 Физическая  модель проектируемой базы данных

 

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

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

Модель трансформации:

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

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

DBMS модель:

Модель трансформации  напрямую переводится в DBMS модель, которая, в свою очередь, получает определения  объектов физической базы данных в  схеме RDBMS или каталоге базы данных. ERwin напрямую поддерживает эту модель с функцией генерации схемы. Первичные ключи становятся уникальными индексами. Альтернативные ключи и инверсные вхождения (Inversion Entries, IE) также могут стать индексами.

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

Рисунок 2 – Физическая модель базы данных

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

 

 

 

 

 

 

 

 

 

4 Создание форм, запросов и отчетов в среде СУБД Visual FoxPro

 

Visual FoxPro состоит из  отдельных компонентов, которые  используются для хранения информации, ее отображения и редактирования. В Visual FoxPro вся информация хранится  в базе данных, которая состоит  из таблиц, отношений между таблицами, индексов, триггеров и хранимых процедур. Каждая таблица имеет уникальное имя и хранится в отдельном файле, наименование которого совпадает с именем таблицы. Структура таблиц и связи между ними в Visual FoxPro представлена на рисунке 3.

 

 

Рисунок 3 – Структура таблиц и связей между ними в Visual FoxPro

 

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

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