Технология проектирования и администрирования баз данных и систем данных-Конспект

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

ВВЕДЕНИЕ

Курс «Технология проектирования и администрирования баз данных и систем данных»:

Назначение и основные компоненты системы баз данных; обзор современных систем управления базами данных (СУБД); уровни представления данных; понятия схемы и подсхемы; модели данных; иерархическая, сетевая и реляционная модели данных; схема отношения; язык манипулирования данными для реляционной модели; реляционная алгебра и язык SQL; проектирование реляционной базы данных, функциональные зависимости, декомпозиция отношений, транзитивные зависимости, проектирование с использованием метода сущность-связь; изучение СУБД по выбору: Access, dBASE, FoxРro, Paradox; создание и модификация базы данных; поиск, сортировка, индексирование базы данных, создание форм и отчетов; физическая организация базы данных; хешированные, индексированные файлы; защита баз данных; целостность и сохранность баз данных.

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

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

База знаний (БЗ) содержит сведения о закономерностях в рассматриваемой предметной области, а также информацию о структуре и содержании БД.

1. ДАННЫЕ

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

1.1. Источники данных

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

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

Чтобы понять процесс электронной обработки данных, необходимо знать ряд терминов, которые применяются при описании и представлении данных

[4].

1.1.1. Предметная область

Предметная область может относиться к любому типу организации (например, банк, университет, больница или завод).

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

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

1.1.2. Объект

Объектом может быть человек, предмет, событие, место или понятие, о котором записаны данные.

Так, в банковском деле примерами объектов могут служить КЛИЕНТЫ, БАНКОВСКИЕ СЧЕТА и ССУДЫ ПО ЗАКЛАДНЫМ. На товарном складе —

это ПОСТАВЩИКИ, ТОВАРЫ, ОТПРАВЛЕНИЯ и т д.

1.1.3. Атрибуты (элементы данных)

Каждый объект характеризуется рядом основных атрибутов. Например, дом характеризуется габаритами, цветом, временем эксплуатации и размером приусадебного участка. Клиент банка имеет такие атрибуты, как фамилию, адрес и, возможно, идентификационный номер. Банковский счет может представляться типом, номером и балансом. Объект «КЛИЕНТ» банка описывается тремя атрибутами: идентификационным номером, фамилией и адресом (см. рис. 1.1). Атрибут часто называют элементом данных, полем данных, полем, итемом данных или элементарным итемом.

1.2. Значение данных

Значение данных представляет действительные данные, содержащиеся в каждом элементе данных. Элемент данных «фамилия клиента» может принимать такие значения, как «проф Хиггинс» или «Марк Твен». В зависимости от того, как элементы данных описывают объект, их значения могут быть количественными, качественными или описательными. На рис. 1.1 показаны различия между объектами, элементами данных и принимаемыми ими значениями.

Рис.1.1

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

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

При рассмотрении данных часто бывает трудно выявить различия между объектом, элементом данных и значением элемента данных. Так, если объектом является КЛИЕНТ, то представляющими клиента элементами данных служат его идентификационный номер, фамилия и адрес, а возможными значениями этих элементов данных — «123456789», «проф. Хиггинс» и «55 Сноу Стрит, Нью-Йорк, Н.-Й». Тем не менее установить различия между объектом, элементом данных и значением, которое принимает этот элемент данных, очень важно.

1.2.1. Ключевой элемент данных

Некоторые элементы данных обладают интересным свойством. Зная значение, которое принимает такой элемент данных объекта, мы можем идентифицировать значения, которые принимают другие элементы данных этого же объекта. Например, зная идентификационный номер клиента «123456789», мы можем определить, что это «проф. Хиггинс» и что профессор Хиггинс имеет «открытый» счет в банке. Элементы данных, по которым можно определить другие элементы данных, называются ключевыми. Иногда их называют также идентификаторами объекта.

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

1.2.2. Запись данных

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

1.2.3. Файл данных

Записи данных образуют файл данных: файл представляет собой упорядоченную совокупность записей. На рис. 1.2 показан пример файла в отпечатанном виде — отчет управляющего отделением (выдержка) с записями одного типа. Файл такого типа — с похожими записями (т. е. содержащими

одинаковое число элементов)»—называется «плоским». Файл также может содержать записи различного типа. Иногда файл называют набором данных.

Рис. 1.2

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

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

Рассмотрим задачи, связанные с банковскими операциями (рис. 1.1). Ниже перечисляются проблемы, с которыми приходится сталкиваться в процессе обработки данных при использовании нескольких файлов.

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

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

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

Рис. 1.3

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

•недостаточности средств защиты хранимых данных;

•неадекватности процедур восстановления после возникновения отказов;

•трудностей по обеспечению ведения длинных записей;

•негибкости к изменениям;

•высокой стоимости программирования и сопровождения;

•сложности процедур управления эксплуатацией ЭВМ (небрежность и ошибки)

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

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

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

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

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

1.4.База данных

1.4.1.Определение базы данных

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

Для ведения баз данных раздельно от прикладных программ требуется некоторое расширение обобщенных методов доступа. Это расширение называют «системой управления базами данных» [4] [5].

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

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

1.4).

Рис 1.4

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

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

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

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

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

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

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

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

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

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

•упрощение процедуры эксплуатации ЭВМ.

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

1.5.Администратор базы данных

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