
- •Общие сведения Сведения об эумк
- •Методические рекомендации по изучению дисциплины
- •Рабочая учебная программа
- •Учреждение образования
- •«Белорусский государственный университет
- •Информатики и радиоэлектроники»
- •Пояснительная записка
- •Содержание дисциплины
- •1. Название тем лекционных занятий, их содержание, объем в часах.
- •2 Перечень тем ипр их наименование и объем в часах
- •3 Перечень тем контрольных работ их наименование и объем в часах
- •4. Курсовая работа, ее характеристика
- •Перечень тем курсовых работ
- •5. Литература
- •5.1 Основная
- •5.2 Дополнительная
- •6. Перечень компьютерных программ, наглядных и других пособий, методических указаний и материалов и технических средств обучения
- •7. Учебно-методическая карта дисциплины
- •1.1.3. Способы организации знаний в базах знаний
- •1.1.4. Применение баз знаний
- •1.1.5. Виды моделей баз данных
- •2. Теория баз данных
- •2.1. История развития представлений о базах данных
- •2.1.1. Области применения вычислительной техники
- •2.1.2. Базы данных и информационные системы
- •2.1.3. История развития баз данных
- •2.1.4. Этапы развития баз данных
- •2.2. Основные термины и определения теории бд, виды бд и их отличия
- •2.2.1. Классификация бд
- •2.3. Реляционные бд, понятие сущности и связи
- •2.3.1. Общие определения
- •2.3.2. Факты о реляционной модели данных
- •2.3.3. Достоинства реляционной модели данных
- •2.3.4. Недостатки реляционной модели данных
- •2.3.5. Целостность бд
- •2.3.6. Отношения
- •2.3.7. Кортежи и отношения
- •2.3.8. Связи
- •2.3.9. Ключи отношений
- •2.3.10. Ссылочная целостность
- •2.3.11. Консистентность данных
- •2.4. Многоуровневая архитектура баз данных, понятие физического и логического уровней баз данных
- •2.4.1. Определения
- •2.4.2. Многоуровневая структура баз данных
- •Indexed р#
- •2.4.3. Постоянная и переменная длина записи
- •2.4.4. Способы представления данных
- •2.4.5. Простейший вариант – плоский файл
- •2.4.6. Факторизация по значениям поля
- •2.4.7. Индексирование по полям
- •2.4.8. Комбинация простых представлений
- •2.4.9. Использование цепочек указателей
- •2.4.10. Многосписочные структуры
- •2.4.11. Инвертированная организация
- •2.4.12. Иерархическая организация
- •2.4.14. Промежуточный итог
- •2.4.15. Методы индексирования
- •2.4.16. Индексирование по комбинации полей
- •2.4.17. Селективный индекс
- •2.4.18. Индексация по методу сжатия
- •2.4.19. Фронтальное сжатие
- •2.4.20. Сжатие окончания
- •2.4.21. Символьные указатели
- •2.4.23. Индексно-последовательная организация
- •2.4.24. Сбалансированные деревья
- •2.4.25. Ведение файла
- •2.4.26. Хэширование
- •2.5.2. Факторы эффективности хэширования
- •2.5.3. Размер участка памяти
- •2.5.4. Плотность заполнения
- •2.5.5. Алгоритмы хэширования
- •2.5.6. Размещение записей в области переполнения
- •2.5.7. Итог
- •2.6. Механизмы обработки и хранения данных в бд
- •2.6.1. Введение
- •2.6.2. Механизмы обработки и хранения данных в ms-sql 6.0-6.5
- •2.6.3. Механизмы обработки и хранения данных в ms-sql 7.0 и более поздних версиях
- •2.6.4. Метод доступа isam
- •2.6.5. Метод доспута MyIsam
- •2.6.6. Метод доступа vsam
- •2.6.7. Включение записей в *sam-файлы
- •2.6.8. Размещение индексов для *sam-файлов
- •2.6.9. Метод доступа InnoDb
- •InnoDb в MySql 5.1
- •2.7.3. Сетевые структуры
- •3.1.4. Стандарты разработки бд/субд
- •3.1.5. Sql и его стандарты
- •3.1.6. Использование методологии idef1x
- •3.1.7. Пример логической и физической схемы в ErWin
- •3.1.8. Минимальный набор стандартных таблиц
- •3.1.8. Итог
- •3.2. Средства автоматизированного проектирования бд
- •3.2.1. Введение
- •3.2.2. Case-технологии
- •3.2.3. Достоинства case-технологий
- •3.2.4. Промежуточные выводы и определения
- •3.2.5. Методологии структурного моделирования
- •3.2.6. Методология sadt (idef0)
- •3.2.7. Методологии информационного моделирования
- •3.2.8. Нотация Чена
- •3.2.9. Нотация Мартина
- •3.2.10. Нотация ide1x
- •3.2.11. Нотация Баркера
- •3.2.12. Язык информационного моделирования
- •3.2.13. Case-средства
- •3.2.14. Процесс создания модели бд в ErWin
- •3.2.15. Процесс создания модели бд в Sparx ea
- •3.2.16. Итог
- •3.3. Особенности проектирования бд на логическом и физическом уровнях
- •3.3.1. Введение
- •3.3.2. Модель бд
- •3.3.4. Банки данных
- •3.3.5. Модели данных
- •3.3.6. Этапы проектирования бд
- •3.3.7. Проектирование бд: внешний уровень
- •Изучение процессов преобразования входных данных в выходные.
- •3.3.8. Проектирование бд: инфологический уровень
- •3.3.9. Проектирование бд: даталогический уровень
- •3.3.10. Уровни sql
- •3.3.11. Проектирование бд: физический уровень
- •3.4.3. Требования нормализации
- •3.4.4. Примеры аномалий
- •3.4.5. Нормальные формы
- •3.4.6. Зависимости
- •3.4.6. Первая нормальная форма
- •3.4.7. Вторая нормальная форма
- •3.4.8. Третья нормальная форма
- •3.4.9. Нормальная форма Бойса-Кодда
- •3.4.10. Четвёртая нормальная форма
- •3.4.11. Пятая нормальная форма
- •3.4.12. Доменно-ключевая нормальная форма
- •3.4.13. Ещё раз, кратко, все нормальные формы
- •3.4.14. Ещё раз, кратко, в ErWin
- •3.4.15. Обратное проектирование бд
- •3.4.16. Итог
- •3.5. Повышение качества бд на стадии проектирования
- •3.5.1. Памятки разработчикам бд
- •3.5.2. Показатели качества бд
- •Практическая часть
- •Указания по выбору варианта
- •Индивидуальные практические работы Индивидуальная практическая работа № 1 Общие сведения
- •Практическая часть
- •Указания по выбору варианта
- •Индивидуальная практическая работа № 2 Общие сведения
- •Указания по выбору варианта
- •Практическая часть
3.3.5. Модели данных
Одними из основополагающих в концепции БД являются обобщенные категории «данные» и «модель данных».
Данные – это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие факторы.
Примеры данных: Пупкин Василий Васильевич, $30, красный.
Данные не обладают определённой смысловой структурой, данные становятся информацией тогда, когда пользователь задаёт им определённую смысловую структуру, то есть, осознаёт их смысловое содержание.
Поэтому центральным понятием в области баз данных является понятие модели.
Не существует однозначного определения этого термина, у разных авторов эта абстракция определяется с некоторыми различиями, но, тем не менее, можно выделить нечто общее в этих определениях.
Модель данных – это некоторая абстракция, которая, будучи применена к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними.
Рисунок 3.3.5.1 – Модели данных
В соответствии с рассмотренной ранее трёхуровневой архитектурой мы сталкиваемся с понятием модели данных по отношению к каждому уровню.
Действительно, каждая модель данных оперирует категориями, касающимися организации тех или иных «объектов модели» на том или ином (своём!) уровне.
Наибольший интерес вызывают модели данных, используемые на концептуальном уровне.
По отношению к ним внешние модели называются подсхемами и используют те же абстрактные категории, что и концептуальные модели данных.
Кроме трёх рассмотренных уровней абстракции при проектировании БД существует ещё один уровень, предшествующий им.
Модель этого уровня должна выражать информацию о предметной области в виде, независимом от используемой СУБД.
Эти модели называются инфологическими, или семантическими, и отражают в естественной и удобной для разработчиков и других пользователей форме информационно-логический уровень абстрагирования, связанный с фиксацией и описанием объектов предметной области, их свойств и их взаимосвязей.
Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения, а даталогические модели уже поддерживаются конкретной СУБД.
Как правило, именно с инфологической модели следует начинать проектирование базы данных.
3.3.6. Этапы проектирования бд
Создание и внедрение в практику современных информационных систем выдвигает новые задачи проектирования, которые невозможно решать традиционными приемами и методами.
От того, насколько успешно будет спроектирована база данных, зависит эффективность функционирования системы в целом, её жизнеспособность и возможность расширения и дальнейшего развития.
Поэтому вопрос проектирования баз данных выделяют как отдельное, самостоятельное направление работ при разработке информационных систем.
Проектирование баз данных – итерационный, многоэтапный процесс принятия обоснованных решений в процессе анализа информационной модели предметной области, требований к данным со стороны программистов и пользователей, синтеза логических и физических структур данных, анализа и обоснования выбора программных и аппаратных средств.
Рассматривая вопрос проектирования баз данных, будем придерживаться такого многоуровневого представления данных: внешнего, инфологического, логического (даталогического) и внутреннего.
Такое представление уровней данных – не единственное. Существуют и другие варианты многоуровневого представления данных.
Так, в соответствии с рекомендациями ANSI/X3/SPARC, а также CODASYL (Conference on Data Systems Languages), как правило, выделяется три уровня представления данных:
внешний уровень (с точки зрения конечного пользователя и прикладного программиста),
концептуальный уровень (с точки зрения СУБД),
внутренний уровень (с точки зрения системного программиста).
В соответствии с этой концепцией внешний уровень – это часть (подмножество) концептуальной модели, необходимая для реализации какого-либо запроса или прикладной программы.
То есть, если концептуальная модель выступает как схема, поддерживаемая конкретной СУБД, то внешний уровень – это некоторая совокупность подсхем, необходимых для реализации конкретной прикладной программы или запроса пользователя.
Существует также другая точка зрения, в соответствии с которой под внешним уровнем понимают общие понятия, связанные с изучением и анализом информационных потоков предметной области и их структуризацией.
Некоторые авторы вводят вспомогательный уровень (промежуточный между внешним и даталогическим уровнями), который называется инфологическим. Он может выступать как самостоятельный или быть составной частью внешнего уровня.
Мы будем рассматривать инфологический уровень как самостоятельный уровень представления данных.
Внешний уровень в этом случае выступает как отдельный этап проектирования, на котором изучается всё «внемашинное» информационное обеспечение, то есть формы документирования и представления данных, а также внешняя среда, в которой будет функционировать система с точки зрения методов фиксации, сбора и передачи информации в базу данных.
При проектировании БД на внешнем уровне необходимо изучить функционирование объекта, для которого проектируется БД, всю входную и выходную документацию с точки зрения определения того, какие именно данные необходимо сохранять в базе данных.
Внешний уровень – это, как правило, словесное описание входных и выходных сообщений, а также данных, которые целесообразно сохранять в БД.
Описание внешнего уровня не исключает наличия элементов дублирования, избыточности и несогласованности данных. Поэтому для устранения этих аномалий и противоречий внешнего описания данных выполняется инфологическое проектирование.
Инфологическая модель является средством структуризации предметной области и понимания концепции семантики данных.
Инфологическую модель можно рассматривать в основном как средство документирования и структурирования формы представления информационных потребностей, которая обеспечивает непротиворечивое общение пользователей и разработчиков системы.
Все внешние представления интегрируются на инфологическом уровне, где формируется инфологическая (каноническая) модель данных.
Инфологический уровень представляет собой информационно-логическую модель (ИЛМ) предметной области, из которой исключена избыточность данных и отображены информационные особенности объекта без учёта особенностей и специфики конкретной СУБД.
То есть инфологическое представление данных ориентированно, преимущественно, на человека, который проектирует или использует базу данных.
Логический (концептуальный) уровень построен с учётом специфики и особенностей конкретной СУБД.
Этот уровень представления данных ориентирован больше на компьютерную обработку и на программистов, которые занимаются её разработкой.
На этом уровне формируется концептуальная модель данных, то есть специальным способом структурированная модель предметной области, которая отвечает особенностям и ограничениям выбранной СУБД.
Модель логического уровня, поддерживаемую средствами конкретной СУБД, называют еще даталогической.
Инфологическая и даталогическая модели, отображающие одну предметную область, взаимосвязаны. Инфологическая модель может легко трансформироваться в даталогическую модель.
Внутренний уровень связан с физическим размещением данных. На этом уровне формируется физическая модель БД, которая включает структуры сохранения данных в памяти компьютера, в т.ч. описание форматов записей, порядок их логического или физического приведения в порядок, размещение по типам устройств, а также характеристики и пути доступа к данным.
От параметров физической модели зависят такие характеристики функционирования БД как объём занимаемой памяти и время отклика на команду.
Физические параметры БД можно изменять в процессе её эксплуатации с целью повышения технической эффективности функционирование системы.
Изменение физических параметров не предопределяет необходимости изменения инфологической и даталогической моделей.
Схема взаимосвязи уровней представления данных в БД изображена на рисунке:
Рисунок 3.3.6.1 – Схема взаимосвязи уровней представления данных в БД
От того, насколько квалифицированно спроектирована БД, зависит производительность информационной системы и полнота обеспечения функциональных потребностей пользователей и прикладных программ.
Неудачно спроектированная БД может усложнить процесс разработки прикладного программного обеспечения, обусловить необходимость использования более сложной логики, которая, в свою очередь, увеличит время реакции системы, а в дальнейшем может привести к необходимости перепроектирования логической модели БД.
Реструктуризация или внесение изменений в логическую модель БД – очень нежелательный процесс, поскольку он является причиной необходимости модификации или даже перепрограммирование отдельных задач.
Каждый этап проектирования рассматривается как определённая последовательность итеративных процедур, в результате которых формируется определённая модель БД.