Разработка базы данных по учёту материалов на примере ООО «Спектр»

Реляционная модель данных

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

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.

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

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

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

Проектирование реляционных БД

При проектировании базы данных решаются две основных проблемы:

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

Использование нормализации

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

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

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

• первая нормальная форма (1NF);
• вторая нормальная форма (2NF);
• третья нормальная форма (3NF);
• нормальная форма Бойса-Кодда (BCNF);
• четвертая нормальная форма (4NF);
• пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Основные свойства нормальных форм:

• каждая следующая нормальная форма в некотором смысле лучше предыдущей;
• при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

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

3. Сравнительный анализ систем управления баз данных

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

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

На сегодняшний день известные фирмы производители реляционных СУБД следующие - ORACLE, Informix, IBM (DB2), Sybase, Microsoft (MS SQL Server), Progress и другие. В своих продуктах производители СУБД ориентируются на работу на различных типах компьютеров и на различных операционных системах. Также производители СУБД не обошли вниманием продукты, работающие на настольных компьютерах, такие как dBase, FoxPro, Access и им подобные. Данные СУБД предназначены для работы на РС и решают локальные задачи на одном РС или небольшой группе РС. Конечно, настольные СУБД обладали, обладают и будут обладать всеми недостатками файл-серверной архитектуры. Среди их основных недостатков -  незащищённость данных, медленная работа, трудности с поддержкой ограничений целостности, проблемы с дублированием данных при миграции и резервном копировании, трудности администрирования, катастрофического снижения скорости обработки при возрастании объемов данных и т.д. и т.п. Однако, используемые для решения проблемы средства должны соответствовать сложности решаемой проблемы. Так, вряд ли имеет смысл тратить на разработку и внедрение информационной системы средства, существенно большие, чем весь годовой оборот предприятия, а для многих предприятий сферы малого и среднего бизнеса дело обстоит именно так. Следует понимать, что расходы на приобретение готового программного обеспечения (в частности, серверной СУБД), а также разработку соответствующей информационной системы, функционирующей под управлением это СУБД, составят от нескольких десятков тысяч до нескольких миллионов долларов. На сегодняшний день перечисленные выше СУБД используются, прежде всего, в государственных (муниципальных) учреждениях, сфере образования, сфере обслуживания, малом и среднем бизнесе. Специфика возникающих там задач заключается в том, что объемы данных не являются катастрофически большими, частота обновлений не бывает слишком большой, организация территориально обычно расположена в одном небольшом здании, количество пользователей колеблется от одного до 10-15 человек. В подобных условиях использование настольных СУБД для управления информационными системами является вполне оправданным и с успехом применяется.  Более того, последние версии настольных СУБД приобрели некоторые качества, необходимые для нормальной работы, такие, например, как поддержка ограничений целостности и механизма транзакций. Некоторые настольные СУБД функционируют в среде Microsoft Windows, а также «обзавелись» средствами реализации оконного пользовательского интерфейса, например, Microsoft Access и Visual FoxPro.

Выбор СУБД

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

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

В качестве вариантов построения системы остановимся подробнее на следующих трех ведущих персональных СУБД – Oracle, Visual FoxPro и MS Access 2007. Данный анализ проведем с учетом того, что число клиентских мест не превышает 20 , а управление СУБД должно быть максимально эффективно. Управление системами было возложено на ОС Windows.

Система управления баз данных Oracle

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

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

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

Система управления баз данных Microsoft Visual FoxPro 7.0

Visual FoxPro 7.0 представляет собой новую версию широко известной системы управления базами данных (СУБД) Visual FoxPro, которая функционирует в среде Windows и представляет собой полноценное 32-х разрядное приложение. Visual FoxPro является объектно-ориентированным, визуально-программируемым языком, управляемым по событиям и в полной мере соответствует новым требованиям, предъявляемым к современным средствам проектирования.

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

Отличительной особенностью Visual FoxPro 7.0 является совместимость с предыдущими версиями FoxPro, что позволяет достаточно просто перенести приложения, созданные ранее, в более привлекательную среду Windows.

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

Microsoft Access 2007

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

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

Для выполнения почти всех основных операций Access предлагает большое количество Мастеров (Wizards), которые делают основную работу за пользователя при работе с данными и разработке приложений, помогают избежать рутинных действий и облегчают работу неискушенному в программировании пользователю.

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

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

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