Проектная часть. 
Разработка информационной базы данных для средней школы

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

Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объёма информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых «Системами управления базами данных» (СУБД). Этому предшествовал первый опыт использования файловых систем для организации баз данных. Файловые системы выявили различные проблемы обработки большого количества информации и заложили основные направления развития теории баз данных. Вот список лишь нескольких потребностей, которые не покрывались возможностями систем управления файлами:

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

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

Приведем типовую схему организации работы с СУБД (рис. 2).

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

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

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

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

Рисунок 3. Уровни моделей данных Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инфологическая модель данных «Сущность-связь».

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

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

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

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

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

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

В данном дипломном проекте при построении инфологической модели базы данных была хорошо изучена предметная область. Наложены ограничения на предметную область (рис. 4).

Рисунок 4. Инфологическая схема БД.