Основы проектирования реляционных баз данных
Тип приложения | Определение | ||
---|---|---|---|
1. | OLTP-система | A | - это такое приложение обработки данных, для которого база данных растет или сжимается в размерах периодически в зависимости от характера обработки данных. |
2. | DSS-система | Б | - это приложение, которое обеспечивает аналитическую обработку данных, включающую математический, статистический или иной анализ данных. |
3. | BATCH-системы | В | - это такое приложение, которое работает с базой данных в не интерактивном режиме. |
4. | OLAP-система | Г | - это такое приложение, которое работает с очень большой базой данных в режиме "только чтение". |
5. | VCDB-система | Д | - это такое приложение, которое содержит в основном транзакции вставки, обновления и удаления, с высокой частотой преимущественно транзакций обновления. |
Элементы | Определение | ||
---|---|---|---|
1 | Источники данных | A | показывают места хранения данных. |
2 | Потоки данных | B | показывают операции, производимые над данными. |
3 | Хранилища данных | C | показывают, кто использует или работает с данными. |
4 | Процессы обработки данных | D | показывают способ передачи данных между источниками и хранилищами данных |
Этап | Содержание | ||
---|---|---|---|
1. | Создание логической модели базы данных | A | - это этап, на котором на основании информационной модели предметной области базы данных создается логическая структура базы данных, независимая от ее реализации |
2. | Создание физической модели базы данных: внутренняя схема | B | - это этап, на котором анализируются возможные транзакции системы, выполняется, в случае необходимости, денормализация отношений для обеспечения более высокой производительности базы данных |
3. | Создание физической модели базы данных: учет влияния транзакций | C | - это этап, на котором на основании логической модели базы данных создается физическая структура базы данных, зависимая от ее реализации |
4. | Создание серверного кода | D | - это этап, на котором на основании функциональной модели предметной области базы данных создается серверный код базы данных в виде триггеров, хранимых процедур и пакетов |
5. | Проектирование модулей приложений базы данных | E | - это этап, на котором создаются спецификации модулей приложений, разрабатываются стратегии тестирования базы данных и приложений, создается план тестирования приложений базы данных и готовятся тестовые данные |
6. | Контроль качества проектирования базы данных | F | заключается в настройке некоторых транзакций к базе данных и локальном перепроектировании базы данных согласно требованиям, поступающим с других этапов создания базы данных |
7. | Учет задач обратного влияния | G | заключается в проверке качества результатов проектирования на каждом его этапе |
8. | Сбор и анализ входных данных | H | - это начальный этап проектирования, на котором осуществляется сбор и контроль качества результатов анализа предметной области базы данных, готовится план проектирования базы данных |
Задачи | Результаты | ||
---|---|---|---|
1. | Контроль качества ER-диаграмм | A | Последовательность работ бизнес-модели процесса проектирования базы данных со сведениями об ответственных исполнителях и сроках их исполнения |
2. | Контроль качества диаграмм функциональной модели предметной области базы данных | B | Основа для создания логической модели базы данных |
3. | Систематизация требований заказчика к базе данных | C | Вывод о достаточности требований и реализуемости базы данных |
4. | Подготовка плана проектирования базы данных | D | Основа для разработки серверного кода и проектирования модулей приложений базы данных |
Номер шага алгоритма | Действие | ||
---|---|---|---|
1 | I | А | Формирование списка имен таблиц и их сокращений в словаре данных |
2 | II | Б | Идентификация реляционной таблицы |
3 | III | В | Проверка: число базовых таблиц соответствует числу отношений логической модели реляционной базы данных |
4 | IV | Г | Формирование списка имен колонок и их сокращений в словаре данных |
5 | V | Д | Определение колонок для базовых таблиц |
6 | VI | Е | Определение типов данных колонкам |
7 | VII | Ж | Проверка списка имен в словаре данных, чтобы избежать конфликтов имен в базе данных в целом |
8 | VIII | З | Выборочное добавление |
Алгоритм
Повторение пунктов 2 и 3 для каждого нового отношения, полученного в результате декомпозиции.
Алгоритм
Исходное отношение:
Преподаватель_предмет (Личный_#, Предмет, Часы, Фамилия, Должность, Оклад, Кафедра, Телефон )
Результирующие отношения:
Преподаватель (Личный_#, Фамилия, Должность, Оклад, Кафедра, Телефон )
Предмет(Личный_#, Предмет, Часы )
Комментарий к ответу: Отношение Преподаватель_Предмет содержит частичные ФЗ: пять последних неключевых атрибутов зависят от части ключа Личный_#. Это может привести к следующим аномалиям:
Устранение аномалий заключается в выполнении двух проекций отношения.
Цель: идентификация пользователя и предоставление доступа к приложению базы данных
Входные данные
Имя пользователя
Пароль
Таблица базы данных: USERACCOUNT
Колонки:
USERNAME - запрашивается, используется в предикате поиска
USERPASS - запрашивается, используется в предикате поиска
Действия:
Если пользователя с таким именем и паролем нет в базе данных - отказать в доступе и попросить правильно ввести свои данные (на случай ошибки), но не более трех раз.
Если пользователь есть в базе данных - предоставить доступ к модулю "Главная страница", которая в зависимости от полномочий пользователя может иметь различный внешний вид.
Какая позиция спецификация была пропущена проектировщиком базы данных?