Разработка базы данных

При проектировании программ выясняются запросы и пожелания  клиента и определяется возможный  подход к решению задачи. Задача анализируется. На основе этого анализа  реализуется конкретная модель в  конкретной программной среде. Результаты каждого этапа проектирования используются в качестве исходного материала для следующего этапа. Анализируется текущая организация предприятия, выделяются проблемы для решения, определяются объекты и отношения между ними, составляется «эскиз» текущей организации предприятия, разрабатывается модель с учетом конкретных условий ее функционирования. База данных ориентирована на определенную предметную область, например: учёт товарной продукции, и организована на основе некоторого подмножества данных. Возможности баз данных полезны в областях, связанных с долговременным управлением информацией, таких как электронные библиотеки и хранилища данных. Предварительное планирование, подготовка данных, последовательность создания информационной модели. В первую очередь при проектировании системы обработки данных необходимо решить  вопрос: «Как организовать данные?». Помочь понять организацию данных, призвана информационная модель. Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность переделки в дальнейшем. Требования отдельных пользователей должны быть представлены в едином «обобщенном представлении». Последнее называют концептуальной моделью. Объект – это абстракция множества предметов реального мира, обладающих одинаковыми характеристиками и законами поведения. Объект представляет собой типичный неопределенный экземпляр такого множества. Объекты объединяются в классы по общим характеристикам. Например, в предложении «Белый Дом является зданием», «Белый Дом» представляет объект, а «здание» – класс. Классы обозначаются абстрактными существительными. Класс – это множество предметов реального мира, связанных общностью структуры и поведением.

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

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

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

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

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

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

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

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

Объект «Остатки» позволяет всегда быть в курсе имеющихся товаров на складе.

Объект «Единицы измерения» позволяет измерить товары в количественном эквиваленте.

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

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

Логическая  модель отражает логические связи между  элементами данных вне зависимости  от их содержания и среде хранения.

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

Рисунок 15 – Логическая модель

Как видно из логической схемы, база данных будет состоять из следующих восьми сущностей:

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

2) накладные строки – если прочитать название полей, то станет ясно, что в таблице храниться информация о товарах «привязанных» по коду к какой-либо накладной.

3) клиенты – в данном случае под видом лица понимается поставщик или потребитель, в случае если  клиент  является поставщиком тогда ставиться галочка в поле «Вид лица».

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

5) товары – содержит список товаров, использующийся в различных операциях.

6) единицы измерения – в поле «Название» пишется полное название единицы измерения, например: «килограммы», а поле «СокрНазвание» его сокращённое название: «кг», это сделано для удобства и экономии места на формах ввода/вывода.

7) цены товара – Таблица хранит информацию обо всех ценах для товаров, которые были назначены на определённую дату.

8) остатки – содержится информация о товарах имеющихся в складских помещениях.

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

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

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

Степень независимости  данных определяется тщательностью  проектирования базы данных. Всесторонний анализ объектов предметной области  и их взаимосвязей минимизирует влияние  изменения требований к данным в  одной программе на другие программы.

Описание таблиц:

«Накладная», регистрирует приходные и расходные операции

Таблица 1–Накладная

№	Название	Тип, доп инф.
1	Накладная	Счетчик, первичный  ключ
2	Номер	Текстовый (50)
3	Приход	Логический
4	Клиент	Числовой
5	Дата	Дата/время
6	Ответственный	Числовой
7	Комментарий	Текстовый (250)
8	Обработана	Дата/время

Для регистрации  типа накладной используется логическое поле №3. В поле №6 будет ссылаться на таблицу «ОТВЕТСТВЕННЫЕ» по числовому значению. Поля №5 и №8 имеют тип дата/время.

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

 

Таблица 2–Накладные строки

№	Название	Тип, доп инф.
1	НакладнаяСтроки	Счетчик, первичный  ключ
4	Количество	Числовой
5	Единица измерения	Числовой
6	Цена	Денежный
7	Сумма	Денежный

 

Все поля таблицы  за исключением цены и суммы, являются числовыми которые, по их значениям  ссылаются на другие таблицы базы данных (далее БД). Поле №6 равно цене ед. товара, а поле №7 равно поле №4 умноженное на №7.

«Клиенты», содержит информацию о поставщиках и заказчиках.

Таблица 3–Клиенты

№	Название	Тип, доп инф.
1	Клиент	Счетчик, первичный  ключ
2	Вид лица	Логический
3	Наименование  общества	Текстовый (10)
4	Полное название орг	Текстовый (150)
5	ФИО	Текстовый (50)
6	Адрес	Текстовый (150)
7	Телефон	Числовой (20)

 

В поле №2 имеющее  тип логический отличает значением  «истина» поставщика от клиента.

«Ответственные лица», через ключевое поле №1, эта таблица связывается с таблицей «накладные».

Таблица 4–Ответственные лица

№	Название	Тип, доп инф.
1	Код ответственного	Счетчик, первичный  ключ
2	ФИО	Текстовый (50)
3	Должность	Текстовый (50)
4	Адрес	Текстовый (50)
5	Телефон	Числовой (20)