
- •Общие сведения Сведения об эумк
- •Методические рекомендации по изучению дисциплины
- •Рабочая учебная программа
- •Учреждение образования
- •«Белорусский государственный университет
- •Информатики и радиоэлектроники»
- •Пояснительная записка
- •Содержание дисциплины
- •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.1.8. Итог
В завершение можно еще раз перечислить все таблицы, которые потребовались для системного каталога:
Структура данных
DataTypes – типы данных
Tables – таблицы
Columns – поля в таблицах
Пользователи
People – люди
Users – пользователи системы
Groups – группы пользователей
UsersInGroups – вхождения пользователей в группы
Журнал изменений
Transactions – транзакции
Changes – изменения, произведенные транзакциями
Перечисления
Enumerations – наборы значений
Параметры
Parameters – параметры
Сообщения
Messages – сообщения
3.2. Средства автоматизированного проектирования бд
3.2.1. Введение
Проектирование баз данных – логически сложная, трудоёмкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов.
В процессе создания и функционирования информационных систем (ИС) потребности пользователей постоянно изменяются и уточняются, что ещё более усложняет разработку и сопровождение БД для таких систем (и самих систем).
Проблемы, с которыми сталкивается аналитик, взаимосвязаны – и это является одной из главных трудностей в их решении.
Аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика. Заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, полезным и необходимым, а что – нет.
Аналитик сталкивается с чрезмерным количеством сведений о предметной области и о новой системе, а спецификация системы из-за объёма и технических терминов часто непонятна для заказчика.
В случае понятности спецификации для заказчика, она будет являться недостаточной для проектировщиков и программистов, создающих систему.
Эти проблемы могут быть существенно облегчены за счёт применения современных структурных методов, среди которых центральное место занимают методологии структурного анализа.
3.2.2. Case-технологии
CASE-технология (Computer-Aided Software/System Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимоувязанных средств автоматизации.
CASE-технология – это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования и разработки ПО.
При использовании методологий структурного анализа появился ряд ограничений (сложность понимания, большая трудоёмкость и стоимость использования, неудобство внесения изменений в проектные спецификации и т.д.)
С самого начала CASE-технологии развивались с целью преодоления этих ограничений путём автоматизации процессов анализа и интеграции поддерживающих средств.
3.2.3. Достоинства case-технологий
Единый графический язык
CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать визуальное представление компонентов разрабатываемой системы в виде простой и ясной структурой.
Компоненты системы представляются двумерными схемами (которые проще в использовании, чем многостраничные описания), позволяющими заказчику участвовать в процессе разработки, а разработчикам – общаться с экспертами предметной области, разделять деятельность системных аналитиков, проектировщиков и программистов, а также обеспечивать лёгкость сопровождения и внесения изменений в систему.
Единая БД проекта
Основа CASE-технологии – использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая может разделяться между разработчиками в соответствии с их правами доступа.
Содержимое репозитория включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонентов.
Репозиторий может хранить множество типов объектов: структурные диаграммы, определения экранов и меню, проекты отчётов, описания данных, логику обработки, модели данных, их организации и обработки, исходные коды, элементы данных и т.п.
Интеграция средств
На основе репозитория осуществляется интеграция CASE-средств и разделение системной информации между разработчиками.
При этом возможности репозитория обеспечивают несколько уровней интеграции:
общий пользовательский интерфейс по всем средствам;
передачу данных между средствами;
интеграцию этапов разработки через единую систему представления фаз жизненного цикла;
передачу данных и средств между различными платформами.
Поддержка коллективной разработки и управления проектом
CASE-технология поддерживает групповую работу над проектом, обеспечивая возможность работы в сети, экспорт-импорт любых фрагментов проекта для их развития и/или модификации, а также планирование, контроль, руководство и взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов.
Эти функции также реализуются на основе репозитория. В частности, через репозиторий может осуществляться контроль безопасности (ограничения и привилегии доступа), контроль версий и изменений и т.п.
Макетирование
CASE-технологии дают возможность быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на ранних этапах разработки оценить, насколько она приемлема для будущих пользователей и устраивает его.
К слову: прототипирование является одной из очень мощных (хоть и дорогих) «техник извлечения требований», активно используемой в рамках обеспечения качества программного обеспечения.
Генерация документации
Многая документация по проекту генерируется автоматически на базе репозитория.
Несомненное достоинство CASE-технологий заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитории (известно, что при традиционных подходах к разработке ПО документация в лучшем случае запаздывает, а ряд модификаций вообще не находит в ней отражения).
Примечание: да, не 100% документации может быть сгенерировано автоматически. Но очень много «шаблонных, рутинных действий» по её генерации может быть автоматизировано.
Верификация проекта
CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом.
По некоторым статистическим данным ошибки проектирования и кодирования составляют соответственно 2/3 и 1/3 от общего числа ошибок, а ошибки проектирования примерно в 100 раз труднее обнаружить на этапе сопровождения ПО, чем на этапе анализа требований.
Другой подход к анализу распределения ошибок показывает, что до 50% ошибок зарождается на стадии разработки требований. Ещё до 25% – на стадии проектирования. На стадию кодирования приходится около 10% ошибок.
Автоматическая генерация объектного кода
Генерация части кода на том или ином языке программирования осуществляется на основе репозитория и позволяет автоматически построить некоторую часть объектного кода или текстов на языках высокого уровня.
Сопровождение и реинжиниринг
Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга и обратного инжиниринга позволяют создавать модель системы из её кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кода и т.п.