Базы данных    
Конспект лекций
назад | содержание | вперед

 

Раздел 1. Системы файлов и базы данных

В этом разделе обсуждаются следующие темы:

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

     · происхождение современных баз данных от файлов и файловых структур

     · недостатки управления данными в файловых структурах

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

     · типы систем и модели баз данных.

 

Тема 1.1. Введение в базы данных

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

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

        · invoice number (номер счета-фактуры) = 300124

        · invoice date (дата выписки счета) = 12-JAN-2002

        · sales amount (сумма платежа) = $125.98

Далее предположим, что эти два подразделения компании Восход в первый квар­тал 2004 года и первый квартал 2005 года выписали 1380456 и 1453907 счетов-фактур соответственно. Следовательно, множество неупорядоченных сведений ком­пании Восход будут содержать 2 834 363 номеров счетов-фактур, 2 834 363 дат выписки этих счетов и 2 834 363 сумм платежей. Принимая во внимание столь обильный фактический материал, к которому необходимо присовокупить информа­цию о сотрудниках каждого из этих двух подразделений, работавших в каждом из этих кварталов, можно ли всерьез думать о том, что руководство компании сможет извлечь какую-то продуктивную информацию об эффективности сделок в расчете на одного сотрудника каждого из этих двух подразделений? Скорее всего, нет.

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

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

Выделим из всего сказанного выше некоторые основные положения.

        · Неструктурированные, "сырые"сведения — это основной источник информации.

        · Информация структурируется путем обработки"сырых" сведений.

        · В структурированной информации выявляется ее предназначение.

        · Достоверная, существенная и своевременная информация – ключ к принятию верных решений.

        · Верные решения – ключ к успеху предприятия на мировом рынке.

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

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

        · данные конечных пользователей, т. е. сведения, отражающие сферу интересов конечного пользователя;

        ·метаданные, или данные о данных, с помощью которых осуществляется интегрирование (объединение) данных.

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

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

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

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

            · Каков объем продаж (в долларах) продукции за последние шесть месяцев?

            · Каков размер вознаграждения для каждого коммивояжера за последние три месяца?

            · Сколько клиентов имеют долг по кредиту в размере $3000 и более?

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

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

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

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

Рис. 1.1. СУБД управляет взаимодействием между конечным пользователем и базой данных

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

Почему так важно проектирование базы данных.Хорошая база данных не получается случайно, структура ее содержимого должка тщательно прорабатываться. Даже хорошая СУБД будет плохо работать с неудачно спроектированной базой данных. Правильно спроектированная БД облегчает управление данными и становится цен­ным поставщиком информации. Плохо спроектированная БД вероятнее всего станет накопителем избыточной информации, т. е. неоправданного дублирования данных. Избыточность, как правило, затрудняет выявление ошибок в данных. База данных содержит избыточные данные, если одна и та же информация об одном и том же логическом объекте хранится в разных местах (логическим объектом, сущно­стью — entity — считается персона, местоположение или предмет, сведения о которых подлежат сбору и хранению). Например, избыточность данных имеет место, если но­мер телефона клиента хранится и в файле клиентов, и в файле коммивояжеров, и в файле счетов-фактур. Избыточность данных может стать источником несовместимости данных, когда трудно определить, какая информация является правильной, а какая нет (например, если телефон клиента был заменен новым только в файле счетов-фактур, а в других остался прежним). В отчетах, выполненных на основе такой информации, могут содержаться противоречивые сведения в зависимости от того, какая из версий данных была использована. Короче говоря, неконтролируемая избыточность данных — типичный признак плохо спроектированной БД.

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

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

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

 

 

Тема 1.2. Предыстория баз данных: файлы и системы файлов

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

Хотя файловые структуры в настоящее время постепенно уходят в прошлое, есть несколько веских причин для их детального изучения:

      · файловые структуры представляют собой интересную ретроспективу способов обработки данных;

      · философ Джордж Сантаяна однажды заметил, что "те, кто не помнит прошлое, обречены его повторить". Некоторые из дефектов, свойствен­ных файловым структурам, могут вновь появиться в программном обеспечении БД, если его пользователям не будут известны ошибки управления данными;

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

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

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

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

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

      ·Какой продукт продавался лучше всего на прошлой неделе?

      ·Каков объем сделок в долларах за текущий день, неделю, месяц, квартал, год?

      ·Каково положение дел с продажами в настоящий момент времени по сравнению с прошлой неделей, прошлым месяцем или прошлым годом?

      · Какие статьи расходов увеличились, уменьшились или остались на прежнем уровне в течение прошлой недели, месяца или года?

      · Не свидетельствует ли уровень продаж о необходимости пополнить складские запасы торговой точки?

И этот список пополняется с каждым днем!

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

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

Хранение в файлах. Перевод картотеки в соответствующую файловую структуру компьютера был доста­точно сложной технической задачей. По этой причине возникла потребность в профессионалах особого рода — специа­листах по обработке данных (Data Processing specialist, DP), которых необходимо было нанять или "взрастить" из имеющихся сотрудников. DP-специалист умел стро­ить необходимые структуры файлов, зачастую разрабатывая и программное обеспе­чение, помогающее управлять данными в таких структурах, а также писал приклад­ные программы, которые автоматически создавали необходимые отчеты на основе данных файла. В то время было порождено огромное число компьютеризованных систем файлов.

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

 

          C_NAME - Имя клиента
          C_PHONE- Телефон клиента
          C_ADDRESS - Адрес клиента
          С_ZIP - Почтовый индекс клиента
          A_NAME - Имя агента
          A_PHONE - Телефон агента
          ТР - Тип страховки
          AMT - Сумма страхового полиса
          REN - Дата обновления страховки

Рис. 1.2 Структура пользовательского файла Customer

 

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

Таблица 1.1. Основная терминология файловых систем

Используя терминологию файловых систем, представленную в табл.1.l, мы можем идентифицировать компоненты файла, показанные на рис. 1.2. Обратите внимание что файл CUSTOMER (клиент), представленный на рис. 1.2, содержит 10 записей. Каждая запись состоит из девяти полей: C_NAME (имя), C_PHONE (телефон C_ADDRESS (адрес),C_ZIP(почтовый индекс),(имя),A_PHON (телефон), ТР (тип), АМТ и REN. Все 10 записей хранятся в именованном файле. Поскольку файл, представленный на рис. 1.2, содержит информацию о клиенте, файлу присвоено имя CUSTOMER.

На основе содержимого файлов типа CUSTOMER DP-специалист писал програм­мы, создававшие необходимые отчеты для коммерческого отдела:

      ежемесячные сводки, в которых отражены типы и размеры страховых полисов, проданных каждым агентом (такие отчеты используются при анализе деятельно­сти каждого агента);

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

      отчеты, анализирующие соотношение типов страховых полисов, проданных каж­дым агентом;

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

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

Затем в коммерческом отделе был создан файл с названием SALES (продажи), по­могающий следить за ежедневными сделками. По мере необходимости получения новых отчетных форм были созданы дополнительные файлы. На самом деле успеш­ная деятельность коммерческого отдела стала столь очевидной, что и руководитель отдела кадров попросил привлечь DP-специалиста для автоматизации обработки платежных ведомостей, а также других функций. В результате DP-специалиста по­просили создать файл AGENT (агенты), представленный на рис. 1.3. Данные в фай­ле AGENT использовались для выписки чеков, отслеживания уплаты налогов, ито­говых результатов страхования и т. д.

          A_NAME - Имя агента
          A_PHONE - Телефон агента
          A_ADDRESS - Адрес агента
          A_ZIP - Почтовый индекс агента
          HIRED - Дата приема агента на работу
          YTD_PAY - Оплата на сегодняшний день
          YTD_FIT - Налоги, оплаченные на сегодняшний день
          YTD_PICA - Оплата социального страхования
          YTD_SIS - Объем продаж на сегодняшний день
          DEP - Число иждивенцев

Рис. 1.3. Содержимое файла AGENT

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


Рис. 1.4. Простейшая система файлов

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

 

 

Тема 1.3. Оценка системы файлов

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

      осмысление недостатков системы файлов позволит нам понять причины возник­новения и развития баз данных;

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

 

1.3.1. Управление системой файлов

Алгоритмизация даже простейшей задачи поиска требует достаточно интенсивного использования языков программирования третьего поколения (third-generation lan­guage — 3GL). Эти языки программирования предполагают, что программист дол­жен определить как то, что необходимо сделать, так и то, как это необходимо вы­полнить. К языкам 3GL относятся, например, COBOL (COmmon Business-Oriented Language), BASIC (Beginner's All-purpose Symbolic Instruction Code) и FORTRAN (FORmula TRANslation).

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

Необходимость написания программ на языках 3GL для создания даже самых про­стых отчетов делает практически невозможной обработку нерегламентированных запросов. Принятых на работу DP-специалистов, работающих со сложившейся системой файлов, нередко просят создать новые отчеты. Чаще всего они вынуждены давать ответ вроде "зайдите на следующей неделе" или даже "через месяц". Однако если информация вам требуется немедленно, то вполне веро­ятно, что "на следующей неделе" или в "следующем месяце" она не будет иметь ни­какого смысла.

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

      · создание структуры файла

      · добавление данных в файл;

      · удаление данных из файла;

      · изменение данных в файле;

      · вывод содержимого файла.

Даже простая система, состоящая из 20 файлов, потребует 5х20 = 100 управляю­щих программ. Если к каждому из этих файлов осуществляется доступ из 10 различных программ, генерирующих отчеты, то необходимо написать дополнительно 20х10=200 программ. Поскольку нерегламентированные (в данном случае неза­программированные) запросы невозможны, число программ генерации отчетов бы­стро умножается. А если каждый отдел организации является единоличным хозяи­ном своих данных и создает собственные файлы, то общее число таких файлов растет очень быстро.

Тщательное планирование структур файлов является очень важной обязанностью DP-менеджеров, поскольку изменение существующей структуры файла — дело слишком трудоемкое. Например, чтобы изменить только одно поле в исходном файле CUSTOMER, потребуется написать программу, которая должна выполнять следующие действия.

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

      2. Открыть исходный файл, используя другой буфер.

      3. Считать запись из исходного файла.

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

      5. Записать преобразованные данные в новую файловую структуру.

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

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

Структура файлов и недостаточная безопасность создают определенные трудности при накоплении данных. Такая организация обработки данных способствует их мо­нопольному использованию, побуждая таким образом хранить одну и ту же инфор­мацию в различных местах. Поскольку маловероятно, что данные, хранящиеся в разных местах, будут всегда согласованно обновляться, то файлы часто содержат различные версии одних и тех же данных. Результат использования системы файлов легко предсказать: хотя такой подход лег­ко реализуется на начальных стадиях компьютерной обработки данных, по мере роста системы она, скорее всего, выйдет из-под контроля. Очевидно, что системы файлов не могут удовлетворять современным требованиям, предъявляемым к информационным системам.

 

1.3.2. Структурная зависимость и зависимость по данным

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

Даже изменение свойств данных файла, например, изменение типа поля с integer (целое) на decimal (десятичное) потребует изменений во всех программах, исполь­зующих этот файл. Поскольку необходимо поменять все программы доступа к дан­ным при любых изменениях характеристик данных файла, говорят, что система файлов обладает зависимостью по данным (data dependence).

Практический смысл зависимости по данным состоит в разнице между логическим форматом данных (data logical format — как видит данные человек) и физическим форматом данных (data physical format — как "видит" данные компьютер). Поэтому всякая программа, получающая доступ к файлу, должна сказать компьютеру не только, что надо делать, но и как делать. Именно поэтому каждая программа долж­на содержать строки кода, в которых задаются способ открытия файлов конкретного типа, спецификация его записей и определения полей. Зависимость по данным, таким образом, делает систему файлов чрезвычайно громоздкой и с точки зрения программирования, и с точки зрения управления.

 

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

Если в файловой системе возникли трудности с обработкой данных, то весьма веро­ятно, что в различных местах хранятся одинаковые данные. Например, на рис.1. 2 и 1.3 имена агентов и номера телефонов встречаются как в файле CUSTOMER, так и в файле AGENT, хотя на самом деле достаточно иметь всего лишь один набор имен агентов и список их телефонных номеров. Если же они встречаются в нескольких местах, то имеет место избыточность данных.

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

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

Ошибки оператора наиболее вероятны при вводе сложных элементов (например, десятизначных телефонных номеров) в несколько разных файлов и/или при час­то повторяющемся вводе в один или более файл. На самом деле, файл CUSTOMER содержит такую ошибку ввода: в третьей записи файла CUSTOMER переставлены цифры в номере телефона аген­та (615-882-2144 вместо 615-882-1244).

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

      Аномалия данных. Словарь определяет термин "аномалия" как отклонение, ненор­мальность. В идеальном случае изменение значения поля должно выполняться только в одном месте. Тем не менее, избыточность данных приводит к тому, что возникает необходимость производить такие изменения в множестве различных мест. Взгляните на файл CUSTOMER. Если агент решит выйти замуж и сменить место жительства, то имя агента придется изменить, по всей видимости, адрес и номер телефона тоже. Вместо того чтобы внести такие изменения в единственной записи файла AGENT, мы должны исправить эту информацию во всех записях файла CUSTOMER, где встречается этот агент! Нам предстоит также проделать сотни исправлений в записях каждого клиента,] связанного с этим агентом. Такая же проблема возникает при увольнении агента. Каждому клиенту, обслуживаемому уволившимся агентом, необходимо назначить нового. Обратите внимание, что аномалии данных существуют именно потому, что в целях обеспечения целостности данных любые изменения в каждом поле необходимо правильно выполнить во многих местах. Аномалии данных, которые имеются на рис. 1.2, в общем случае определяются так:

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

           · аномалии включения. Чтобы добавить нового клиента в файл CUSTOMER. также необходимо ввести данные по агенту. Если мы добавляем несколько сотен новых клиентов, то нам придется ввести и несколько сотен имен агентов и не меньшее количество телефонных номеров. Опять-таки в этом случае высока вероятность несовместимости данных;

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

 

Тема 1.4. Системы баз данных

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


Рис. 1.5. Отличие базы данных от системы файлов

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

 

1.4.1. Среда системы базы данных

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

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

Рис.1.6. Среда системы базы данных

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

           · Системное программное обеспечение управляет всеми компонентами оборудо­вания и обеспечивает доступ к нему всем другим приложениям, работающим на компьютере. Примеры системного программного обеспечения: DOS, операционные системы семейства Windows, устанавливаемые на персональ­ных компьютерах, системы UNIX и VMS, используемые, как правило, на компьютерах средней мощности, и операционная система MVS, которая ус­танавливается на мэйнфреймах фирмы IBM.

           · Программное обеспечение СУБДуправляет базой данных. Примерами СУБД являются приложения Access и SQL Server корпорации Microsoft, Oracle кор­порации Oracle и DB2 фирмы IBM.

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

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

           · Системные администраторы наблюдают за основными операциями системы.

           · Администраторы базы данных (DBA) управляют работой СУБД и обеспечивают функционирование базы данных.

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

           · Системные аналитики и программисты color:black'> пишут и реализуют прикладные про­граммы. Они проектируют и создают формы ввода данных, отчеты и про­цедуры, с помощью которых конечные пользователи получают доступ к дан­ным и возможность манипулирования ими.

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

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

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

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

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

 

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

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

По количеству пользователей СУБД можно подразделить на однопользовательские (single-user) и многопользовательские (multiuser). Однопользовательская СУБД обслу­живает в данный момент времени только одного клиента. Другими словами, если пользователь А использует базу данных, то пользователи В и С должны подождать, пока пользователь А не закончит работу с базой. Если однопользовательская БД развернута на персональном компьютере, то ее называют настольной базой данных (desktop database). В противоположность этому, многопользовательская СУБД может обслуживать несколько пользователей одновременно. Если многопользовательская база данных обслуживает относительно небольшое число пользователей (менее 50) или, скажем, отдел предприятия, то она называется базой данных рабочей группы (workgroup database). Если же база данных используется в рамках всего предприятия и обслуживает большое число (более 50, как правило, сотни) пользователей не­скольких подразделений и отделов, то такая БД называется базой данных предпри­ятия (enterprise database).

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

Возможно, классификация СУБД по способу применения и сфере использования базы данных является самым распространенным и общепризнанным способом. На­пример, транзакции по продаже товаров или услуг, платежи и закупка товаров пред­ставляют собой важнейшие каждодневные операции. Время, которое отводится на выполнение таких транзакций, весьма ограничено, а результат их действий должен фиксироваться и вступать в силу немедленно. СУБД, которые управляют работой баз данных, спроектированных для транзакций "немедленного отклика", называются транзакционными СУБД (transactional DBMS) или рабочими СУБД (production DBMS)1. В отличие от них база данных поддержки решений (decision support database) предна­значена в основном для получения необходимой информации при выработке стра­тегических или тактических решений на уровне среднего и высшего руководства предприятия. Поддержка решений, обеспечиваемая системой поддержки решений (decision support system, DSS), как правило, требует широкомасштабной обработки данных (манипулирования данными) для извлечения полезной информации из дан­ных, полученных за некоторый длительный промежуток времени, с тем, чтобы при­нять верное решение по ценовой политике, спрогнозировать сбыт, состояние рынка и т. д. Поскольку основная часть информации DSS извлекается из накопленных за некоторое время сведений, фактор времени, затраченного на получение данных в такой системе, не имеет столь существенного значения, как в транзакционных базах данных. К тому же информация систем DSS, как правило, базируется на большом объеме данных, полученных из различных источников. Чтобы облегчить поиск в этом море информации, структура базы данных DSS несколько отличается от структуры транзакционных БД. На самом деле, для обозначения баз данных, предназначенных для систем DSS, используется термин хранилище данных, или банк данных (Data Warehouse, DW).

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

 

1.4.3. Предназначение СУБД

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

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

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

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

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

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

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

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

      Языки доступа к данным и интерфейсы 2 прикладного программирования. СУБД обеспечивает доступ к данным с помощью языка запросов. Язык запросов это не­процедурный язык, т.е. он предоставляет пользователю возможность определять, что необходимо выполнить, без необходимости указывать, как это нужно вы­полнять. В состав языка запросов СУБД входят два основных компонента: язык определения данных (data definition language, DDL) и язык манипулирования данными (data manipulation language, DML). DDL определяет структуры, в которых разме­щаются данные, a DML позволяет конечным пользователям извлекать данные из БД. СУБД также предоставляет программистам доступ к данным из процедурных языков третьего поколения (3GL), таких как COBOL, С, PASCAL, Visual Basic и др. В составе СУБД имеются административные утилиты, предназначенные для администраторов базы данных (DBA) и проектировщиков БД, для внедрения, текущего контроля и обслуживания базы данных.

      Интерфейсы взаимодействия с базой данных. Текущее поколение СУБД обеспечивает специальные программы взаимодействия, разработанные для того, чтобы БД могла принимать запросы конечных пользователей в сетевом окружении. Фактически возможности взаимодействия с базой данных являются неотъемлемой составляющей современных СУБД. Например, СУБД предоставляет функции взаимодействия для получения доступа к базе данных, используя в качестве внешнего интерфейса интернет-браузер (такой как Netscape или Internet Explorer). В подобной среде взаимодействие может осуществляться несколькими способами:

           · конечный пользователь может получать ответ на запросы, заполняя экранные формы с помощью выбранного им браузера;

           · с помощью СУБД можно автоматизировать публикациюформ отчетов в Интернете с помощью Web-форматирования, что позволяет просматривать их с помощью любого браузера;

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

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

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


назад | содержание | вперед