Данные и управление базами данных

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

Недостатки файловой организации данных

Избыточность данных

Некоторые элементы данных неизбежно используются во многих программах. Поскольку данные требуются нескольким программам, они часто записываются в несколько наборов данных (файл), т.е. одни и те же данные хранятся в различных местах на носителях информации. Такое положение называют "избыточностью" данных. Оно делает достаточно сложным обеспечение непротиворечивости данных. Избыточность данных требует наличия специальных процедур ввода, обновления и формирования отчета, которые приходится неоднократно применять при изменении информации об объектах предметной области.

Ограничения по доступности данных

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

Для решения вышеуказанных проблем введены понятия систем с базами данных.

База данных

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

В чем же состоит основное различие между базой данных и файлом?

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

Основные требования к базе данных:

1. Сокращение избыточности данных (обеспечение минимальной избыточности).

2. Обеспечение целостности.

3. Разграничение доступа.

4. Обеспечение независимости представления данных.

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

Для решения проблем управления базами данных были использованы две концепции:

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

2. Концепция администратора базы данных (АБД).

Системы управления базами данных (СУБД)

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

Основные требования, которым должны удовлетворять СУБД:

· эффективное выполнение одной и той же СУБД различных функций по обработке данных предметной области;

· минимизация избыточности хранимых данных;

· представление непротиворечивой информации для принятия решений;

· обеспечение управления безопасностью;

· отсутствие повышенных требований к персоналу, связанному с разработкой, поддержанием и совершенствованием прикладных программ;

· простая физическая реорганизация базы данных;

· возможность централизованного управления базой данных.

Функции администратора базы данных (АБД)

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

Недостатки интеграции данных

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

Независимость данных

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

· каков формат данных?

· где они располагаются?

· как к ним обратиться?

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

Уровни независимости данных

В настоящее время существуют три уровня абстракции для определения структуры базы данных (рис.60):

– концептуальный;

– логический;

– физический.

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

Рисунок 60 – Два уровня независимости данных

Обычно различают три типа (бинарных) связей между экземплярами объектов:

– один к одному

– один ко многим

– многие ко многим

¨ один к одному (1:1).

Пример:

Покупатель имеет одну фамилию. Свойство единствен-

ности существует в обоих направлениях.

Покупатель Фамилия

¨ один ко многим (1:n).

Пример:

Продавец обслуживает более чем одного покупателя, но каждый

покупатель обслуживается одним продавцом.

Покупатель Продавец

¨ - многие ко многим (m:n).

Пример:

Заказ состоит из многих товаров, а каждый товар может быть

заказан многими покупателями.

Покупатель Товар

Таким образом, концептуальная модель является, по существу, моделью предметной области.

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

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

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

Пользователям выделяются подмножества этой логической модели, называемые внешними моделями.

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

Логическая модель отображается в физическую память, такую как диск, дискета.

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

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

Независимость данных является одним из важнейших требований к базе данных.

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

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

Процесс разработки структуры базы данных в соответствии с требованиями пользователей называется проектированием базы данных.

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

1. Что представляют собой требования пользователей, и в какой форме они могут быть выражены?

2. Как эти требования могут быть преобразованы в эффективную структуру базы данных?

3. Как часто и каким образом структура базы данных должна перестраиваться в соответствии с новыми или изменяющимися требованиями?

Термины "внутренняя модель", "концептуальная модель" и "внешняя модель" соответствуют терминологии группы изучения систем управления базами данных Американского национального института стандартов (ANSI/X3/Sparc).

Проектирование базы данных состоит, по крайней мере из двух этапов:

1. Проектирование логической структуры базы данных, которая поддерживается СУБД;

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

Основные компоненты процесса проектирования базы данных показаны на рисунке 61.

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

Требования к обработке данных состоят из трех характерных компонентов:

¨ специфические элементы данных,

¨ объем данных (число экземпляров данных),

¨ частоты обработки данных для каждого приложения.

Проектировщик использует и другие компоненты такие, как характеристики (или ограничения), СУБД или конфигурация операционной системы и технических средств.

Рисунок 61 – Основные компоненты процесса проектирования базы данных

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