- •Общие сведения Сведения об эумк
- •Методические рекомендации по изучению дисциплины
- •Рабочая учебная программа
- •Учреждение образования
- •«Белорусский государственный университет
- •Информатики и радиоэлектроники»
- •Пояснительная записка
- •Содержание дисциплины
- •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.7.1 – Обобщённая схема процесса изучения документов и данных при проектировании на внешнем уровне
Такое изучение необходимо провести по каждой функциональной задаче или их комплексу, которые будут решаться с помощью БД.
Результатом проектирования на внешнем уровне будет перечень атрибутов (реквизитов) оперативной и условно-постоянной информации, которые необходимо хранить в БД, с указанием источников их получения и формы представления.
Однако этот перечень не исключает возможности существования в нём избыточности, дублирования, несогласованности и других недостатков.
Поэтому на этом процесс не заканчивается, а осуществляется переход к этапу инфологического проектирования.
3.3.8. Проектирование бд: инфологический уровень
Основными составными элементами инфологической модели являются сущности (информационные объекты), связи между ними и их атрибуты (свойства).
Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных.
Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д.
Необходимо различать такие понятия, как «тип сущности» и «экземпляр сущности». Понятие «тип сущности» относится к набору однородных личностей, предметов, событий или идей, выступающих как целое.
Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Минск, Москва, Киев и т.д.
Атрибут – поименованная характеристика сущности.
Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определён для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.).
Атрибуты используются для определения того, какая информация должна быть собрана о сущности.
Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д.
Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: красный, синий, зелёный и т.д., однако, каждому экземпляру сущности присваивается только одно значение атрибута.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Связь – ассоциирование двух или более сущностей.
Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то её структура могла бы быть очень простой.
Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определённые связи.
А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено очень много связей.
Наличие такого множества связей и определяет сложность инфологических моделей.
Требования и подходы к инфологическому проектированию.
Целью инфологического проектирования является создание структурированной информационной модели ПО, для которой будет разрабатываться БД. При проектировании на инфологическом уровне создается информационно-логическая модель (ИЛМ), которая должна отвечать следующим требованиям:
обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных;
корректность схемы БД;
простота и удобство использования на следующих этапах проектирования, то есть ИЛМ может легко отображаться на модели БД, которые поддерживаются известными СУБД (сетевые, иерархические, реляционные и др.);
ИЛМ должна быть описана языком, понятным проектировщикам БД, программистам, администратору и будущим пользователям.
Суть инфологического моделирования, таким образом, состоит в выделении сущностей, которые подлежат хранению в БД, а также в определении атрибутов объектов и взаимосвязей между ними.
Существует два подхода к инфологическому проектированию: анализ объектов и синтез атрибутов.
Подход, который базируется на анализе объектов, называется нисходящим, а на синтезе атрибутов – восходящим.