Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Производительность СУБД




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

 

Направления развития СУБД

Анализ современных СУБД позволяет выделить следующие направления их развития:

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

· разработка новых архитектур СУБД;

· расширение областей применения СУБД;

· поиск более совершенных моделей представления и типов данных в базах;

· комбинирование Web-технологий и баз данных;

· разработка хранилищ данных;

· стандартизация СУБД и др.

 

 

5. Базы знаний

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

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

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

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

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

База знаний является основным компонентом экспертных систем.

Элементом базы знаний является фрейм.

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

Продукционная модель – это модель, основанная на представлении знания в виде правил “Если (условие), то (действие)”. Под “ условием” понимается некоторое предложение-образец, по которому осуществляется поиск в базе знаний, а под “ действием” - действия, выполняемые при успешном исходе поиска.

При использовании продукционной модели исходные данные хранятся в базе данных, а набор правил предметной области – в базе знаний. На основе базы данных запускается программа ‑ машина ввода (интерпретатор правил), управляющая перебором правил из базы знаний.

Контрольные вопросы

53. Сформулируйте определения понятий «База данных», «Система управления базами данных».

54. Какими средствами достигнуто свойство независимости данных в базах.

55. Охарактеризуйте три уровня представления данных в базах.

56. Опишите функциональные возможности СУБД.

57. Назовите признаки классификации СУБД.

58. Изложите суть компьютерной архитектуры Клиент – сервер.

59. Приведите примеры современных серверных СУБД.

60. Сформулируйте определения понятий «знания», «база знаний».

61. Назовите элементы базы знаний.

62. Что такое фрейм?

 


 

Лекция 13

 

Проектирование баз данных

63. Этапы проектирования базы данных.

64. Процесс проектирования базы данных. Предварительный этап и этап концептуального проектирования

65. Логическое проектирование базы данных

66. Этап физического проектирования.

67. Проектирование базы данных учебного примера.

1. Этапы проектирования баз данных

Процесс проектирования БД обычно осуществляется в 3-4 этапа.

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

Этап 1: (Предварительный). Анализ Предметной Области и требований к будущей системе баз данных.

Результат: наборы информационных потребностей различных групп пользователей.

Этап 2: Концептуальное проектирование (инфологическое моделирование). Сбор информации о Предметной Области и представление ее в формализованном виде.

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

Результат: Концептуальная схема и внешние схемы пользователей (или инфологическая модель)

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

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

Результат: Логическая схема данных, в терминах выбранной модели данных и СУБД

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

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

2. Процесс проектирования БД

Предварительный этап и этап концептуального проектирования

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

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

Одна из методик формализации описания предметной области называется: "Объект-Свойство-Связь".

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

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

Преимущества подхода “Объект - Свойство - Связь” — как самого популярного из подходов семантического моделирования — таковы:

· независимость от дальнейшей реализации;

· интуитивные основные понятия;

· отражение семантики предметной области (смысла каждого объекта, связи, свойства).

Особенно важно то, что использование подхода “ Объект – Свойство – Связь” позволяет сохранить не только данные, но и частично смысл (семантику) этих данных.

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

Объекты и их свойства

Рассмотрим основные понятия семантического моделирования.

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

Тип сущностей определяет набор объектов с одним и тем же набором свойств. Экземпляр сущности – конкретный объект в наборе.

Например, если мы хотим описать преподавателей университета, то все те общие свойства, которые присущи всем преподавателям (это может быть «Табельный номер», «Фамилия», «Должность», «Педагогический стаж»), сформируют тип сущности ПРЕПОДАВАТЕЛЬ. Тогда каждый отдельный преподаватель является экземпляром сущности ПРЕПОДАВАТЕЛЬ.

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

Свойство (attribute, атрибут) – поименованная характеристика сущности, которая принимает значения из некоторого множества значений (домена).

Для идентификации экземпляра типа сущности используются специальные свойства. Это может быть одно или несколько свойств, значения которых позволяют однозначно отличать один экземпляр сущности от другого. Этот набор специальных свойств называется первичным ключом. Например, в типе сущностей ПРЕПОДАВАТЕЛЬпервичным ключом следует объявить поле ТАБЕЛЬНЫЙ НОМЕР, так как это поле будет иметь уникальное значения для каждого преподавателя.

Анализ свойств различных объектов показал, что свойства бывают:

а) единичные и множественные

Единичное свойство — каждый экземпляр типа сущности имеет единственное значение этого свойства.

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

Пример 4. 1

Тип сущностей “Сотрудник”: свойство “Фамилия” – единичное: Иванов, Петров, Сидоров. Свойство “Дети” – множественное: сотрудник может иметь несколько детей: Катя, Сеня.

Б) статичные и динамичные

Статичное свойство не меняется с течением времени, в отличие от динамичного свойства.

Пример 4. 2

Тип сущностей “Сотрудник”: свойство ”Год_рождения” – статичное, свойство “Ученая_степень” – динамичное.

В) обязательные и условные свойства

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

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

Пример 4. 5

Тип сущностей “сотрудник”: свойство “Ученая степень” – условное, так как его присутствие необязательно у экземпляров ЛИЧНОСТЕЙ (таких как секретарь-референт, ассистент), а свойство “Фамилия” – обязательное.

Г) составные свойства

Пример 4. 6

Тип сущностей “сотрудник”: свойство «Адрес» составное:

«адрес» = «город» + «улица» + «дом» + «квартира», где символ «+» означает «конкатенация

строк»

Свойство «дата_рождения» = «год» + «месяц» + «день» – тоже составное.

Различают следующие типы сущностей: простые, т. Е. неделимые сущности, и сложные сущности. Сложные сущности бывают:

· составные – соответствуют отображению «целое – часть» (например, компьютер – устройства);

· обобщенные – соответствует отображению «род – вид» или «супертип – подтип» (например, принтер: лазерный, струйный, матричный);

· агрегированные – соответствует обычно какому-либо процессу, в который вовлечены другие объекты.

Взаимоотношения объектов: связи

В предметной области объекты взаимодействуют друг с другом посредством связей (relationships).

Взаимодействия между двумя сущностями, например, Преподаватели и Экзамены представлены фразами «принимает несколько» и «принимается одним». Преподаватель принимает несколько экзаменов, но каждый экзамен принимается лишь одним преподавателем.

В связи может участвовать два и более объектов. Связи, в которых участвуют два объекта, называются бинарными. Связи, в которых участвуют три объекта, – тернарные, и т. Д. Различают такие типы связей: «один – к – одному» (1:1), «один – ко – многим» (1:M), «многие – ко –многим» (N:M).

Связь «один – к – одному» означает, что каждому экземпляру одного типа сущностей соответствует один экземпляр другого типа сущностей, и наоборот (рис. 4.1, а).

Связь «один – ко – многим» означает, что каждому экземпляру одного типа сущностей (А) соответствуетодин или более экземпляров другого типа сущностей (В), однако каждому экземпляру типа сущностей В соответствует только один экземпляр типа сущностей А. (рис. 4.1, б).

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

 

 

 
 

 

 


А) Один – к – одному б) Один – ко – многим в) Многие – ко – многим

Рис. 13.1. Виды связей между таблицами

Моделирование внешних представлений пользователей

о предметной области

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

Разработчик системы базы данных на основании этих сведений выполняет такие шаги:

68. Неформальное описание предметной области с точки зрения конкретной группы пользователей.

69. Разбор описания с целью определения (вычленения) типов сущностей и их свойств.

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

71. Определение ограничений на значения свойств, на типы связей. Для атрибутов определяется область их значений, например, "фамилия" сотрудника есть текстовая строка длиной не больше 50 символов. Для связей определяется тип отображения (например, один к одному, один ко многим, многие ко многим)?

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

73. Формализация результатов шагов 1-5 и создание внешней схемы БД для этой группы пользователей. На этом шаге создаются формальные спецификации внешнего представления.

74. Объединение внешних представлений в единое концептуальное представление.

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

Графическое представление Предметной Области.

Диаграммы “Сущность - Связь” Чена

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

Наиболее известна модель графического представления концептуальной схемы базы данных, созданная Питером Ченом (первая статья, посвященная этому методу, появилась в 1967г.). Она называется "модель "Сущность-Связь" (Entity-Relationship model, ER-model). Особенностью этой модели является то, что части предметной области, соответствующие объектам, свойствам и связям изображаются в виде диаграмм.

Основные графические символы (примитивы)

модели «Сущность-Связь»

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

Таблица 13.1

Графические примитивы модели «Сущность-Связь»

Название примитива Одно из современных обозначений
Сущность
Свойство
Первичный Ключ
Связь

 

Инструменты визуализации схемы базы данных

Очевидно, что самих ER-диаграмм недостаточно, так как на диаграммах отсутствует такая информация как:

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

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

· информации о разделении доступа к экземплярам сущности.

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

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

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

Другое название для подобного класса инструментального программного обеспечения: CASE-системы (Computer Aided Software Engineering).

Наиболее известные CASE –системы, поддерживающие проектирование баз данных и файлов с использованием ER-модели, таковы: Prokit Workbench, DESIGN/IDEF, VISIO, DESIGNER (ORACLE), ERWin (LogicWorks), SILVERRUN ERX(Computer Systems Advisers).

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

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

3. Логическое проектирование базы данных

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

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

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

а). Перепроверка связей типа 1:1.

б). Удаление связей M:N. Такие связи устраняются путем определения некоторой промежуточной сущности.

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

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

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

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

Первоначально были сформулированы три нормальных формы. Впоследствии были определены нормальные формы более высоких порядков. Однако они не получили широкого распространения

Первая, вторая и третья нормальные формы

Отношение соответствует первой нормальной форме (1NF), если оно удовлетворяет следующим требованиям:

· отношение не должно иметь повторяющихся записей;

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

Отношение соответствует второй нормальной форме (2NF), если оно удовлетворяет следующим требованиям:

· отношение должно находиться в 1-й нормальной форме;

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

Отношение находится в третьей нормальной форме, если оно удовлетворяет следующим требованиям:

· оно должно находиться во 2-й нормальной форме;

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

4. Физическое проектирование базы данных




Поделиться с друзьями:


Дата добавления: 2014-10-31; Просмотров: 1480; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.081 сек.