Реферат - Проблемы проектирования базы данных: концептуальная, логическая и физическая модели
Подождите немного. Документ загружается.
о поставщиках, набора экземпляров записей, содержащих информацию о
материалах, и т.д. Концептуальная запись вовсе не обязательно должна совпадать
с внешней записью, с одной стороны, и с хранимой записью — с другой.
Концептуальное представление определяется с помощью концептуальной
схемы, включающей определения для каждого существующего типа
концептуальных записей (см. рис. 3). Концептуальная схема использует другой
язык определения данных — концептуальный. Чтобы добиться независимости
данных, нельзя включать в определения концептуального языка какие-либо
указания о структурах хранения или методах доступа. Определения
концептуального языка должны относиться только к содержанию информации.
Это означает, что в концептуальной схеме не должно быть никакого упоминания
о представлении хранимого файла, упорядоченности хранимых записей,
индексировании, хеш-адресации, указателях или других подробностях хранения
данных или доступа к ним. Если концептуальная схема действительно
обеспечивает независимость данных в этом смысле, то внешние схемы.
определенные на основе концептуальной, заведомо будут обеспечивать
независимость данных.
Концептуальное представление — это представление всего содержимого
базы данных, а концептуальная схема — это определение такого представления.
Однако было бы ошибкой полагать, что концептуальная схема представляет
собой не более чем набор определений, весьма напоминающих простые
определения записей в программе на языке COBOL (или каком-либо другом
языке). Определения в концептуальной схеме могут включать большое
количество различных дополнительных аспектов обработки данных, например
таких, как ограничения защиты или требования поддержки целостности данных.
Более того, некоторые авторитетные специалисты предлагают в качестве
конечной цели создания концептуальной схемы описание всего предприятия — не
только самих его данных, но и того, как эти данные используются, как они
перемещаются внутри предприятия, для чего используются в каждом конкретном
месте, какая проверка и иные типы контроля применяются к ним в каждом
отдельном случае и т.д. Однако необходимо подчеркнуть, что ни одна
сегодняшняя система реально не поддерживает такого концептуального уровня,
который хотя бы немного приблизился к указанной выше степени развитости. В
большинстве существующих систем концептуальная схема в действительности
представляет собой нечто, что лишь немного больше простого объединения всех
независимых внешних схем с привлечением дополнительных средств
безопасности и поддержкой правил обеспечения целостности. Вероятно, со
временем системы будут гораздо "интеллектуальнее" в поддержке
концептуального уровня.
1.2.3 Внутренний уровень
Третьим уровнем архитектуры является внутренний уровень. Внутреннее
представление— это низкоуровневое представление всей базы данных как базы,
состоящей из некоторого множества экземпляров каждого из существующих
типов внутренних записей. Термин "внутренняя запись" относится к
терминологии ANSI/SPARC и означает конструкцию, иначе называемую
хранимой записью (в дальнейшем мы будем использовать именно этот термин).
Внутреннее представление, так же как внешнее и концептуальное, отделено от
физического уровня, поскольку в нем не рассматриваются физические записи,
обычно называемые блоками или страницами, и физические области устройства
хранения, такие как цилиндры и дорожки. Другими словами, внутреннее пред-
ставление предполагает наличие бесконечного линейного адресного
пространства. Особенности методов отображения этого адресного пространства
на физические устройства хранения в значительной степени зависят от
используемой операционной системы и по этой причине не включены в общую
архитектуру.
Внутреннее представление описывается с помощью внутренней схемы,
которая определяет не только различные типы хранимых записей, но также
существующие индексы, способы представления хранимых полей, физическую
упорядоченность хранимых записей и т.д. Внутренняя схема описывается с
использованием еще одного языка определения данных — внутреннего.
В заключение отметим, что в некоторых исключительных ситуациях
прикладные программы, в частности те, которые называются утилитами, могут
выполнять операции непосредственно на внутреннем, а не на внешнем уровне.
Конечно, использовать такую практику не рекомендуется, поскольку она связана
с определенным риском с точки зрения безопасности (правила безопасности
игнорируются) и сохранения целостности данных (правила целостности тоже
игнорируются). К тому же такая программа будет зависеть от обрабатываемых
данных. Однако иногда подобный подход может быть единственным способом
реализации требуемой функции или достижения необходимого быстродействия
(так же, как пользователю языка высокого уровня иногда по тем же причинам
необходимо прибегнуть к языку ассемблера).
1.3 Избыточное дублирование данных и аномалии
Следует различать простое (неизбыточное) и избыточное дублирование
данных. Наличие первого из них допускается в базах данных, а избыточное
дублирование данных может приводить к проблемам при обработке данных.
Приведем примеры обоих вариантов дублирования.
Пример неизбыточного дублирования данных представляет приведенное на
рис. 5 отношение С_Т с атрибутами Сотрудник и Телефон. Для сотрудников,
находящихся в одном помещении, номера телефонов совпадают. Номер телефона
4328 встречается несколько раз, хотя для каждого служащего номер телефона
уникален. Поэтому ни один из номеров не является избыточным. Действительно,
при удалении одного из номеров телефонов будет утеряна информация о том, по
какому номеру можно дозвониться до одного из служащих.
С_Т
Сотрудник Телефон
Иванов 3721
Петров 4328
Сидоров 4328
Егоров 4328
Рис. 5 Неизбыточное дублирование
Пример избыточного дублирования (избыточности) представляет
приведенное на рис. 6а отношение С_Т_Н, которое, в отличие от отношения С_Т,
дополнено атрибутом Н_комн (номер комнаты сотрудника). Естественно
предположить, что все служащие в одной комнате имеют один и тот же телефон.
Следовательно, в рассматриваемом отношении имеется избыточное дублирование
данных. Так, в связи с тем, что Сидоров и Егоров находятся в той же комнате, что
и Петров, их номера можно узнать из кортежа со сведениями о Петрове.
С_Т_Н
Сотрудник Телефон Н_комн
Иванов 3721 109
Петров 4328 111
Сидоров 4328 111
Егоров 4328 111
а)
С_Т_Н
Сотрудник Телефон Н_комн
Иванов 3721 109
Петров 4328 111
Сидоров — 111
Егоров — 111
б)
Рис. 6 Избыточное дублирование
На рис. 6б приведен пример неудачного отношения С_Т_Н, в котором вместо
телефонов Сидорова и Егорова поставлены прочерки (неопределенные значения).
Неудачность подобного способа исключения избыточности заключается в
следующем. Во-первых, при программировании придется потратить
дополнительные усилия на создание механизма поиска информации для
прочерков таблицы. Во-вторых, память все равно выделяется под атрибуты с
прочерками, хотя дублирование данных н исключено. В-третьих, что особенно
важно, при исключении из коллектива Петрова кортеж со сведениями о нем будет
исключен из отношения, а значит уничтожена информация о телефоне 111-й
комнаты, что недопустимо.
Возможный способ выхода из данной ситуации приведен на рис. 7. Здесь
показаны два отношения С_Н и Н_Т, полученные путем декомпозиции исходного
отношения С_Т_Н. Первое из них содержит информацию о номерах комнат, в
которых располагаются сотрудники, а второе - информацию о номерах телефонов
в каждой из комнат. Теперь, если Петрова и уволят из учреждения и, как
следствие этого, удалят всякую информацию о нем из баз данных учреждения, это
не приведет к утере информации о номере телефона в 111-й комнате.
Т_Н
Телефон Н_комн
3721 109
4328 111
С_Н
Сотрудник Н_комн
Иванов
109
Петров
111
Сидоров
111
Егоров
111
Рис. 7. Исключение избыточного дублирования
Процедура декомпозиции отношения С_Т_Н на два отношения С_Н и Н_Т
является основной процедурой нормализации отношений.
Избыточное дублирование данных создает проблемы при обработке
кортежей отношения, названные Э. Коддом «аномалиями обновления
отношения». Он показал, что для некоторых отношений проблемы возникают при
попытке удаления, добавления или редактирования их кортежей.
Аномалиями будем называть такую ситуацию в таблицах БД, которая
приводит к противоречиям в БД, либо существенно усложняет обработку данных.
Выделяют три основные вида аномалий: аномалии модификации (или
редактирования), аномалии удаления и аномалии добавления.
Аномалии модификации проявляются в том, что изменение значения одного
данного может повлечь за собой просмотр всей таблицы и соответствующее
изменение некоторых других записей таблицы.
Так, например, изменение номера телефона в комнате 111 (рис. 6а), что пред-
ставляет собой один единственный факт, потребует просмотра всей таблицы
С_Т_Н и изменения поля Н_комн согласно текущему содержимому таблицы в
записях, относящихся к Петрову, Сидорову и Егорову.
Аномалии удаления состоят в том, что при удалении какого-либо данного из
таблицы может пропасть и другая информация, которая не связана напрямую с
удаляемым данным.
В той же таблице С_Т_Н удаление записи о сотруднике Иванове (например,
но причине увольнения или ухода на заслуженный отдых) приводит к
исчезновению информации о номере телефона, установленного в 109-й комнате.
Аномалии добавления возникают в случаях, когда информацию в таблицу
нельзя поместить до тех пор, пока она неполная, либо вставка новой записи
требует дополнительного просмотра таблицы.
Примером может служить операция добавления нового сотрудника все в ту
же таблицу С_Т_Н. Очевидно, будет противоестественным хранение сведений в
этой таблице только о комнате и номере телефона в ней, пока никто из
сотрудников не помещен в нее. Более того, если в таблице С_Т_Н поле Служащий
является ключевым, то хранение в ней неполных записей с отсутствующей
фамилией служащего просто недопустимо из-за неопределенности значения
ключевого поля.
Вторым примером возникновения аномалии добавления может быть
ситуация включения в таблицу нового сотрудника. При добавлении таких записей
для исключения противоречий желательно проверить номер телефона и
соответствующий номер комнаты хотя бы с одним из сотрудников, сидящих с
новым сотрудником в той же комнате. Если же окажется, что у нескольких
сотрудников, сидящих в одной ком-пате, имеются разные телефоны, то вообще не
ясно, что делать (то ли в комнате несколько телефонов, то ли какой-то из номеров
ошибочный).
1.4 Базы данных в Internet и intranet
Технология intranet по существу представляет собой технологию Internet,
перепесенную в среду корпоративных ИС. Архитектура информационных систем
в Internet и intranet является результатом эволюционного перехода от первых
многопользовательских централизованных вычислительных систем
(мэйнфреймов) через системы типа клиент-сервер к распределенным системам с
централизованной обработкой и подготовкой информации к непосредственному
потреблению. Рассмотрим кратко указанные этапы эволюции.
1. В мэйнфреймах (рис. 8) вычислительные ресурсы, хранимые данные и
программы обработки информации сконцентрированы в одной ЭВМ. Основным
средством доступа был алфавитно-цифровой терминал (дисплей), управляемый
ЭВМ. Вся обработка информации и подготовка ее к выдаче выполнялись на
центральной ЭВМ. С терминалов, как правило, в машину передавались коды
нажатия клавиш или содержимое буфера экрана, а обратно на терминал —
пересылались отображаемые экраны с соответствующими кодами управления
отображением.
Рис. 8. Централизованная многопользовательская система
Достоинством системы является простота администрирования, защиты
информации и модификации системы, к недостаткам можно отнести высокую
загрузку процессоров и линий связи (как следствие — невысокую реакцию
системы при большом количестве пользователей), низкую надежность (выход из
строя ЭВМ приводит к полному отказу всей системы), сложность
масштабирования системы и некоторые другие.
2. Исторически следующим решением в области информационных систем
была архитектура клиент-сервер (рис. 9).
В этих системах место терминала заняла ПЭВМ, а мэйнфрейма —
компьютер-сервер. Ранее мы рассматривали спектр моделей подобных систем с
различным распределением функций между компонентами. Если не брать во
внимание модель «распределенного представления» (по сути повторяет модель
централизованной многопользовательской системы), то можно заключить, что
системы типа клиент-сервер имеют следующие достоинства: высокая живучесть
и надежность, легкость масштабирования, качественный пользовательский
интерфейс, возможность одновременной работы с несколькими приложениями,
высокие характеристики оперативности обработки информации.
Рис. 9. Системы типа клиент-сервер
Основным недостатком клиент-серверных систем является то, что они
ориентированы на данные, а не на информацию. Это требует от пользователя
знания не только предметной области, а и специфики используемой прикладной
программы.
Существенным недостатком можно считать также сложность переноса таких
систем на другие компьютерные платформы и интеграцию с другими пакетами
из-за «закрытости» используемых протоколов взаимодействия компонентов
систем.
Еще один недостаток заключается в сложности администрирования системы
и ее уязвимости при непредсказуемых или злонамеренных действиях
пользователя или компьютерных вирусов.
3. Корпоративные системы intranet, в отличие от систем клиент-сервер,
ориентированы не на данные, а на информацию в ее окончательном и пригодном
для использования неквалифицированным пользователем виде (рис. 10).
Рис. 10. Системы, поставляющие информацию
Новые системы объединяют в себе преимущества централизованных
многопользовательских систем и систем типа клиент-сервер. Им присущи
следующие черты:
• на сервере порождается информация, пригодная для использования, а не
данные (например, в случае СУБД — записи БД);
• при обмене между клиентской и серверной частями используется протокол
открытого стандарта, а не какой-то конкретной фирмы;
• прикладная система находится на сервере, и поэтому для работы
пользователя на компьютере-клиенте достаточно иметь программу-навигатор
(могут быть и другие решения, когда часть обработки производится на
компьютере-клиенте).
В случае, когда источником информации в Internet и intranet являются БД,
имеет место взаимодействие компонентов WWW и традиционных СУБД.
Различают два следующих варианта функционирования программного
обеспечения WWW по доступу к БД: на стороне Web-сервера (рис. 11а) и на
стороне Web-клиента (рис. 11б).
Рис. 11. Модели доступа к базе данных в Internet
В модели доступа к БД на стороне сервера обращение к серверу БД обычно
производится путем вызова программами Web-сервера внешних по отношению к
ним программ в соответствии с соглашениями одного из интерфейсов: CGI
(Common Gateway Interface — общий шлюзовый интерфейс), FastCGI или API
(Application Program Interface — интерфейс прикладного программирования).
Достоинством этой технологии является ускорение выполнения программ,
так как программа выполняется в рамках основного серверного процесса. Сами
программы имеют большую функциональность, чем CGI-сценарии, например,
появилась возможность контролировать доступ к файлам сервера. К
недостаткам спецификации API относятся следующие:
• языковая зависимость — программа может быть написана только на языке,
поддерживаемом данным API. Чаще всего это языки С и C++ (язык Perl, широко
применяемый при написании CGI-скриптов, не применяется);
• слабая защита сервера от ошибок прикладных программ и от возможности
несанкционированного доступа к системным ресурсам, поскольку API-программа
выполняется в адресном пространстве основного процесса сервера;
• программы, как правило, не переносимы на другие программно-аппаратные
платформы, поскольку привязаны к интерфейсу и архитектуре сервера.
Интерфейс FastCGI сочетает преимущества предыдущих технологий и более
близок к интерфейсу CGI. Приложения, написанные в соответствии с ним,
запускаются как отдельные изолированные процессы, но являются постоянно
активными и не завершаются после обращения к данным как CGI-сценарии.
При доступе к БД на стороне клиента основным средством реализации
механизмов взаимодействия Web-клиента и сервера БД является язык Java. Кроме
того, может использоваться JavaScript, разработанный для расширения
возможностей декларативного языка HTML (нет операторов присваивания,
сравнения, математических функций и пр.) на основе добавления процедурных
средств. Программы на языке JavaScript выполняются на компьютере Web-
броузером в режиме интерпретации.
Достоинством модели доступа на стороне сервера является сравнительная
простота программ-навигаторов (Web-клиентов) и удобство администрирования
системы, так как основная часть программного обеспечения находится на машине
Web-сервера. Очевидным недостатком системы является возможное ухудшение
характеристик оперативности получения информации при большой нагрузке на
Web-сервер и нехватке его мощности.
Во второй модели клиентская часть системы оказывается сложнее, чем в
первой. Это усложняет навигатор, но в то же время разгружает Web-сервер.
В сравнительно недавно выпущенных программных продуктах фирмы
Microsoft поддерживаются обе схемы. На стороне клиента (в среде Internet
Explorer) существует возможность использовать динамический HTML, который
реализуется на языке VBScript. Доступ к данным на стороне сервера
осуществляется с помощью так называемых ASP-страниц (Active Server Pages —
активные серверные страницы). ASP-страницы — это сценарии на языке
VBScript, хранящиеся и выполняемые на Web-сервере (Internet Information Server).
2 Общие системные принципы
2.1 Принцип декомпозиции
Принцип заключается в расчленении системы по какому — либо признаку на
составные части и наделению их собственными целями, функциями, согласно
общим целям, функциям системы.
Сама по себе база данных это и есть расчленение на группы элементов с
указанием связей между ними, неизменное на всё время рассмотрения и дающее
представление о системе в целом. Декомпозиция может осуществляться как
вертикально, то есть с образованием уровней, подчиняющихся друг другу снизу
вверх, так и горизонтально.
2.2 Принцип оперативного принятия решения
Решение должно приниматься быстрее чем измениться свойство объекта
управления в качественном или количественном отношении.
Между проектировщиками баз данных и программистами должно быть
постоянное взаимодействие, иначе база данных может быть сделана отлично, но
совершенно не пригодна для создания програмнного обеспечивания, причиной
может быть очень долгое выполнение запросов программы.
2.3 Принцип согласованности
Заключается в том, что все элементы системы должны быть согласованы
между собой с целью достижения максимального эффективности системы. База
данных должна быть спроектированна, так чтобы в ней небыло лишних
сущностей.
2.4 Принцип совместимости (достижимости)
Заключается в том, что множество базовых элементов и их связей должны
принципиально обеспечивать достижение поставленной задачи.
Проектировщик должен правильно выбирать тип связей между таблицами:
один к одному, один ко многим, многие ко многим.
2.5 Принцип реализуемости
Принцип гласит о том, что цель должна быть достигнута с помощью
элементов, которые могут быть реализованы современными техническими
средствами.
Например, если сайт используемый базу данных был размещён на сервере
используемый СУБД MySQL, был пересен на Microsoft SQL Server, то нужно
будет писать конвертор из одной базы в другую.
2.6 Принцип типизации и стандартизации
В проектируемой системе максимально должны использоваться стандартные
типовые детали, что снижает ее себестоимость.
Можно создавать таблицы используя простой текстовый редактор и
добавлять их в базу данных при помощи .bat файла, также можно создавать и
добавлять базу данных используя СУБД, что намного сократит время создания.
2.7 Принцип самоорганизации (гибкости)
Система должна обладать возможностью изменять свои свойства за счёт
изменения своей структуры.
Примером, иллюстрирующим этот принцип, может послужить использование
запроса. При различных условиях запрос будет выдавать разную информацию,
предусмотренные проектировщиком – программистом.
3 Проблемы управления базой данных
При использовании баз данных связанной с например с сайтом можно
столкнуться с несколькими проблемами, например, атака хакера, сбои в работе
сервера и др. Их можно считать возмущениями.
Тогда управление базой данных подчиняется комбинированному принципу
управления, состоящему из принципов управления по обратной связи и по
возмущению.
Принцип управления по обратной связи заключается в такой организации
взаимодействия элементов в системе, при которой принятие решения
осуществляется не только по информации о целях системы, но и по фактическому
её состоянию. Принцип управления по возмущению заключается в такой
организации взаимодействия элементов в системе, при которой принятие решения
осуществляется ещё и с учётом действующих возмущений.
4 Модели
4.1. Иерархическая модель
В иерархической модели связи между данными можно описать с помощью
упорядоченного графа (или дерева). Упрощенно представление связей между
данными в иерархической модели показано на рис. 12.
Для описания структуры (схемы) иерархической БД на некотором языке
программирования используется тип данных «дерево».
Тип «дерево» схож с типами данных «структура» языков программирования
ПЛ/1 и Си и «запись» языка Паскаль. В них допускается вложенность типов,
каждый из которых находится на некотором уровне.
Рис. 12. Представление связей в иерархической модели
Тип «дерево» является составным. Он включает в себя подтипы («поддеревья»), каждый из
которых, в свою очередь, является типом «дерево». Каждый из типов «дерево» состоит из
одного «корневого» типа и упорядоченного набора (возможно пустого) подчиненных типов.
Каждый из элементарных типов, включенных в тип «дерево», является простым или составным
типом «запись». Простая «запись» состоит из одного типа, например, числового, а составная
«запись» объединяет некоторую совокупность типов, например, целое, строку символов и
указатель (ссылку).
Корневым называется тип, который имеет подчиненные типы и сам не
является подтипом. Подчиненный тип (подтип) является потомком по отношению
к типу, который выступает для него в роли предка (родителя). Потомки одного и
того же типа являются близнецами по отношению друг к другу.
В целом тип «дерево» представляет собой иерархически организованный
набор типов «запись».