СУБД на примере предметной области «Оргтехника»

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Глава 3. Проектирование баз данных.

Рассмотрим проектирование БД на примере предметной области «Оргтехника».

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

• перечень поставщиков;
• список служащих;
• сведения о движении товаров.

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

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

СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.

 

 

 

3.1 Сбор  информации о предметной области

 

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

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

• Функциональный подход – он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая СУБД. В этом случае мы можем четко выделить необходимый минимальный набор объектов предметной области, которые должны быть описаны.

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

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

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

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

 

3.2 Построение  информационно-логической модели  данных

 

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

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

Рассмотрим проектирование БД на примере предметной области «Оргтехника».

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

• перечень поставщиков;

• список служащих;

• сведения о движении товаров.

На основании анализа предметной области мы выделили следующие сущности модели «сущность-связь» («Entity Relationship» - ER-модели): «Поставщики», «Служащие», «Товар», «Движение товара».

На основании внимательного анализа предметной области можно выделить следующие сущности модели “сущность-связь”: «Движение товара», «Поставщик», «Служащие», «Товар», «Поставка фирме», «Поставщик», «Служба доставки», «Счет», «Товары» (рисунок 2).

 

Движение товара Код товара Код служащего Код движения товара Код поставщика Вид движения товара Оптовая цена закупки Розничная цена продажи

Поставщик Код поставщика Код товара Фамилия Имя Отчество Телефон Адрес

Товар Код товара Вид Цена Количество

Служащие Код служащего Фамилия Имя Отчество Адрес Телефон Должность Зарплата Образование

Рис.2 – Сущности модели

 

Между выделенными сущностями можно выделить, например, следующие связи:

1. Поставщики поставляют  товар.

2. Служащие принимают  товар.

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

 

Рис. 3 - Приведение инфологической модели системы учета сборки изделий

3.3 Разработка логической структуры БД.

 

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

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

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

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

Рис. 4 - Приведение инфологической модели «Система учёта сборки изделий» к третьей нормальной форме

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

 

3.4 Конструирования структур таблиц

Созданная база данных состоит из четырёх таблиц. В табл. 1 – 4 приведены параметры структуры таблицы базы данных «Оргтехника».

Таблица 1. Описание свойств полей таблицы Postavchik

Name Field	Index	Type	Size	AllowZero-Length
Code Postavchik	Primary Unique	Text	10	Нет
Code Tovara		Text	15	Да
Surname		Text	15	Да
Name		Text	15	Да
Patronymic		Text	15	Да
Address		Text	15	Да
Telephone		Text	15	Да

 

 

Таблица 2. Описание свойств полей таблицы Tovar

Name Field	Index	Type	Size		Allow-Zero-Length		Validation-Text
Code Tovara	Primary Unique	Text	10		Нет
Vid		Text	15		-
Price		Text		15
Quantity		Text		15

 

 

Таблица 3. Описание свойств полей таблицы Dvijenia Tovara

Name Field	Index	Type	Size	AllowZero-Length
Code Dvijenia Tovara	Primary Unique	Text	10	Нет
Vid Dvijenia Tovara		Text	15
Poznichnai Price Prodaji		Text	15	Нет
Optovai Price Zacypki		Text	15	Да
Code Tovara	Index-Foreign	Text	10	Нет
Code Slyjachego	Index-Foreign	Text	10
Code Postavchik	Index-Foreign	Text	10