Проектирование базы данных

База данных.

Введение.

Измерение температуры и давления

Приборы и методы определения параметров рабочих тел.

Отчет по лабораторной работе № 1

по дисциплине: «Техническая термодинамика»

Исполнитель: студент

Группы 5001: П.А.Толстолуцкий

Руководитель: старший

преподаватель: В.Е. Юхнов

Томск-2012

Информационная система (ИС) «Учет товаров на складе» предназначена для автоматизации деятельности зав. складом по учету товаров на складе. Система ориентирована на применение на оптово-розничных складах и позволяет учитывать наличие товара на складе, его поступление, расход и общую стоимость с учетом закупочной и отпускной цены.

В ИС предусмотрены следующие функции:

Ø ведение базы данных (БД);

Ø формирование отчетов;

Ø формирование справок.

Соответственно ИС состоит из БД и следующих подсистем:

Ø управления БД;

Ø ведения БД;

Ø формирования справок;

Ø формирования отчетов по продаже и поступлению товаров.

Информационная система реализована в среде визуального программирования Delphi 6.0 с применением БД в формате Paradox 7.0, которая имеет формат.db и разработана с помощью утилиты Database Desktop.

БД состоит из 3 взаимосвязанных таблиц: «Товар», «Поступление товара», «Продажа товара».

Подсистема формирования справок позволяет формировать справки в реальном масштабе времени.

Подсистема отчетов позволяет вывести данные о поступлении и продаже товара в документ Microsoft Word в виде таблицы.

Подсистема ведения БД предназначена для ввода и редактирования данных в таблицах «Товар», «Поступление товара», «Продажа товара».

:

Проектирование БД «учет товаров на складе» состоит из следующих шагов.

Ø Анализ предметной области.

Ø Концептуальное проектирование

Ø Логическое проектирование

Ø Физическое проектирование

Анализ предметной области включает в себя:

Ø идентификацию функциональной деятельности Вашей предметной области.

Ø идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс «учета товара на складе» идентифицируют такие сущности как ТОВАР, КОНТРАГЕНТ, ПРАЙС.

Ø идентификацию характеристик этих сущностей. Например, сущность КОНТРАГЕНТ может включать такие характеристики как ИНН, Телефон, Расчетный Счет, Банк и т.п.

Ø иерархию между объектами.

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

Наименование товара	Цена	Количество	Дата поступления	Сумма

Наименование товара	Цена	Количество	Дата продажи	Сумма

Далее определяются атрибуты, которые уникальным образом идентифицируют каждый объект. Это необходимо для того, чтобы система могла получить любую единичную строку таблицы. Вы должны определить первичный ключ для каждого из отношений. Если нет возможности идентифицировать кортеж с помощью одного атрибута, то первичный ключ нужно сделать составным – из нескольких атрибутов. Первичный ключ гарантирует, что в таблице не будет содержаться двух одинаковых строк. Во многих СУБД имеется возможность помимо первичного определять еще ряд _­­­­уникальных ключей. Отличие уникального ключа от первичного состоит в том, что уникальный ключ не является главным идентифицирующим фактором записи и на него не может ссылаться внешний ключ другой таблицы. Его главная задача – гарантировать уникальность значения поля. Для этого необходимо разбить данные на 3 таблицы: товар, поступление товара, продажа товара и добавить них ключевые поля соответственно «код товара», «код поступления», «код продажи».

В концептуальном проектировании - основной целью является установка связи между объектами (таблицами и столбцами) и производится очень важная операция для исключения избыточности данных – нормализация таблиц.

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

Ø связь «один – к – одному»;

Ø связь «один – ко – многим»;

Ø связь «многие – ко – многим»;

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

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

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

Дата добавления: 2015-05-09