Много информации это просто груда мусора


Лекция 4. Уровни проектирования баз данных



страница4/9
Дата29.04.2018
Размер1.56 Mb.
ТипЛекция
1   2   3   4   5   6   7   8   9

Лекция 4. Уровни проектирования баз данных

  1. Трехуровневая архитектура ANSI/SPARC

  2. Жизненный цикл БД

    1. Критерии оценки БД

  3. Уровни проектирования БД

Трехуровневая архитектура ANSI/SPARC


Трехуровневая архитектура была впервые предложена в 1975 году Комитетом планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) национального Института Стандартизации США (American National Standard Institute – ANSI). Поэтому модель стала называться ANSI/SPARC.
Цель трехуровневой архитектуры заключается в отделении пользовательского представления БД от ее физического представления. Рассмотрим причины, по которым необходимо выполнить такое разделение:


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




  1. Взаимодействие пользователя с БД не должно зависеть от особенностей хранения в ней данных.




  1. Администратор БД должен иметь возможность изменять структуру хранения данных в БД, не оказывая влияния на пользовательские представления.




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




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

Таким образом, в модели ANSI/SPARC отражение предметной области представлено моделями данных трех архитектурных уровней:




  • внешнего;

  • концептуального;

  • внутреннего.



рис. 1. Трехуровневая архитектура ANSI-SPARC.
Уровень, на котором воспринимают данные пользователи, называется внешним уровнем (external level). СУБД и ОС воспринимают данные на внутреннем уровне (internal level). Концептуальный уровень представления данных предназначен для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга.
Внешний уровень описывает ту часть БД, которая относится к каждому пользователю. Внешний уровень состоит из нескольких различных внешних представлений БД. Каждый пользователь имеет дело с представлением реального мира, выраженным в наиболее удобной для него форме. Внешнее представление содержит только те сущности, атрибуты и связи реального мира, которые интересны пользователю. Другие сущности, атрибуты и связи, которые ему неинтересны, также могут быть представлены в БД, но пользователь может даже не подозревать об их существовании.
Помимо этого, различные представления могут по-разному отображать одни и те же данные. (Например, формат даты).
На внешнем уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных.
Концептуальный уровень представляет обобщающее представление БД. Этот уровень описывает то, какие данные хранятся в БД, а также связи, существующие между ними.
Концептуальный уровень в трехуровневой архитектуре является промежуточным. Этот уровень содержит логическую структуру всей БД (с точки зрения АБД). Однако этот уровень не содержит никаких сведений о методах хранения данных.
Концептуальная схема является «сердцем» БД. Она поддерживает все внешние представления, а сама поддерживается средствами внутренней схемы. Однако внутренняя схема является всего лишь физическим воплощением концептуальной схемы.
Внутренний уровень содержит физическое представление БД в компьютере. Этот уровень описывает, как информация хранится в БД.
Внутренний уровень описывает физическую реализацию БД и предназначен для достижения оптимальной производительности и обеспечения экономного использования дискового пространства.
Ниже внутреннего уровня находится физический уровень (physical level), который контролируется ОС, но под руководством СУБД.
Трехуровневая архитектура СУБД ANSI-SPARC, включающая внешний, концептуальный и внутренний уровни, позволяет обеспечить независимость хранимых данных от использующих их программ: внешний уровень экранирован от приложений системой управления БД, физический уровень экранирован от СУБД операционной системой (ОС) – в согласии с принципом независимости БД как «сверху» (от прикладных программ), так и «снизу» (от вычислительной аппаратуры).
На рис. 2 показано место типов независимости от данных в трехуровневой архитектуре ANSI-SPARC:


рис. 2. Реализация независимости от данных
в трехуровневой архитектуре ANSI-SPARC.

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

Жизненный цикл БД


БД является фундаментальным компонентом более широкого понятия - информационной системы (ИС). Следовательно, жизненный цикл приложений БД неразрывно связан с жизненным циклом ИС. Этапы жизненного цикла БД показаны на рис. 3.

рис. 3. Жизненный цикл БД.
Рассмотрим основные действия, выполняемые на каждом этапе жизненного цикла:


  • Планирование разработки БД. Этап разработки начинается с маркетинга, т. е. исследования рынка программного обеспечения, поиска аналогов, выяснения потребности в БД.

Планирование разработки БД состоит в определении трех основных компонентов:




  • требуемого объема работы;

  • необходимых ресурсов;

  • общей стоимости проекта.

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


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


  • Определение требований к системе. Определение диапазона действия и границ приложения БД, состав его пользователей и областей применения.




  • Сбор и анализ требований пользователей.

Необходимая для проектирования БД информация может быть собрана следующими способами:




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

  • с помощью наблюдений за деятельностью предметной области;

  • посредством изучения документов, которые используются для сбора или представления информации;

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

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

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


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


  • технология структурного анализа и проектирования (Structured Analysis and Design – SAD);

  • диаграммы потоков данных (Data Flow Diagrams – DFD);

  • графики «вход – процесс – выход» (Hierarchical Input Process Output – HIPO).




  • Проектирование БД. Полный цикл разработки включает концептуальное, логическое и физическое проектирование БД.

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


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


  • Выбор целевой СУБД (необязательно). На этом этапе выполняется выбор наиболее подходящей СУБД для приложения БД.




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

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


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


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




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




  • Тестирование. Приложение БД тестируется с целью обнаружения ошибок, а также его проверки на соответствие всем требованиям, выдвинутым пользователями.

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


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


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

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


БД всегда сопровождается документацией, которая содержит следующую информацию:


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




  • руководство программиста - описание способов настройки БД для решения конкретных задач (в некоторых случаях может отсутствовать);




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

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


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


  1. Адекватность – соответствие БД реальной предметной области. Естественно, что БД не должна искажать предметную область. Это является важнейшим требованием к БД, без соблюдения которого бессмысленно соблюдение всех остальных требований.




  1. Полнота – возможность удовлетворения существующих и новых потребностей пользователей. Полнота является одним из проявлений адекватности БД.




  1. Адаптируемость:

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

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


Пример. Необходимо хранить в БД информацию об успеваемости студентов. Может быть предложено два варианта структуры БД для хранения этой информации:

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


Вариант 1:


ФИО

Высшая математика

Иностранный язык

БД



Иванов

5

4

5



Петров

4

5

4


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




  • Таблица содержит только три поля: ФИО, ПРЕДМЕТ, ОЦЕНКА. Для каждого студента будет создано столько записей, сколько экзаменов сдал этот студент.



Вариант 2:


ФИО

Предмет

Оценка

Иванов

Высшая математика

5

Иванов

Иностранный язык

4

Петров

Высшая математика

4

Петров

Иностранный язык

5

……

……

.

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




      1. простота и эффективность внесения изменений. Например, корректировка значений данных в БД.




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




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




  1. Универсальность. Может быть обеспечена разными способами:

    1. реализацией возможности настройки системы на особенности предметной области;

    2. определенными приемами при проектировании структуры БД и программного обеспечения.




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




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




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




  1. Скорость (время) обработки информации (время реакции на запрос). Чаще всего «скоростные» характеристики определяются путем проведения специальным образом подобранных тестов.

Уровни проектирования БД


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


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

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

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




Рис. 4. Уровни моделей данных

Соответствие уровней современного моделирования данных и элементов архитектуры ANSI-SPARC показано на рис. 5:



рис. 5. Соответствие уровней моделирования данных и
элементов архитектуры ANSI-SPARC

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


  1. фактографический – ориентированный на представление хорошо структурированной информации. (реляционная, иерархическая, сетевая модель данных);

  2. документальный – отражающий слабоструктурированную информацию (семантические сети, документальные модели).

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


Различным пользователям в информационной модели соответствуют различные подмножества ее логической модели, которые называются внешними моделями пользователей. Таким образом, внешняя модель пользователя представляет собой отображение концептуальных требований этого пользователя в логической модели и соответствует тем представлениям, которые пользователь получает о предметной области на основе логической модели. Следовательно, насколько хорошо спроектирована внешняя модель, настолько полно и точно информационная модель отображает предметную область и настолько полно и точно работает автоматизированная система управления этой предметной областью.
Во время фазы физического моделирования разработчик создает модель, оптимизированную для конкретного приложения и СУБД, т.е. привязывает даталогическую модель к среде хранения. Это та самая модель, которая и реализуется на практике. Она определяет используемые запоминающие устройства, способы физической организации данных в среде хранения. Физическая модель предметной области иначе называется внутренней моделью. Описание физической структуры БД называется схемой хранения.
Даталогическая и физическая модели (рис. 3) являются компьютеро - ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Физическая модель БД определяет способ размещения данных на носителях (устройствах внешней памяти), а также способ и средства организации эффективного доступа к ним. Организация хранения данных и доступа к ним в значительной степени зависит от принципов и методов управления данными ОС.
Между логическим и физическим проектированием существует постоянная обратная связь, т. к. решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.
В современных СУБД разработчику не предоставляется какого-либо выбора на стадии физического моделирования. Способ хранения БД определяется механизмами СУБД автоматически «по умолчанию» на основе спецификаций концептуальной схемы БД.
Ключевым моментом в проектировании БД является разработка механизмов защиты БД в соответствии с требованиями пользователей. Т. о., уже на концептуальном уровне проектирования пользователи, создавая свои представления БД, определяют также свои требования к безопасности данных в будущей БД. Построение локальных даталогических моделей второго уровня проектирования БД и затем объединение их в единую глобальную даталогическую модель БД также предполагает решение вопросов защиты данных. На уровне физического проектирования БД выполняется реализация механизмов защиты данных, разработанная на предыдущих уровнях проектирования: АБД проводит регистрацию пользователей БД, «раздает» им права доступа к данным и полномочия, реализует механизм представлений для конкретной выбранной СУБД и др. Таким образом, решение вопросов защиты данных в БД является очень важной задачей, проходящей «красной нитью» через все уровни и этапы проектирования БД, является звеном, по вертикали связывающим процесс проектирования БД.
Современная трехуровневая модель проектирования БД, включающая концептуальный, логический и физический уровни, так же, как и трехуровневая архитектура ANSI-SPARC, обеспечивает независимость данных. АБД может при необходимости переписать хранимые данные, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы БД без разрушения существующих приложений.


Каталог: upload -> iblock -> 549
iblock -> Часы-смартфон
iblock -> Руководство пользователя для телефона Apple iPhone 6
iblock -> Руководство по эксплуатации Методика калибровки Технические характеристики. Минимальный радиус кривизны поверхностей контролируемых изделий, 6мм
iblock -> Технические требования
iblock -> Технологические карты
iblock -> Оптимизация процесса восстановления измененных и уничтоженных маркировочных обозначений на блоках двигателей транспортных средств
iblock -> Инструкция по эксплуатации Температурный gsm извещатель Grinson T7 Благодарим Вас за выбор температурного gsm извещателя Grinson T7
549 -> Гост 4011-72 Вода питьевая. Методы измерения массовой концентрации общего железа


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница