- •Содержание
- •1.1. Основные понятия
- •1.2. Компоненты БнД
- •1.3. Классификация БнД и бд
- •1.4. Этапы проектирования бд
- •1.5. Взаимосвязь этапов проектирования бд
- •Вопросы для самоконтроля
- •Раздел 2. Проектирование баз данных. Тема 2. Инфологическое моделирование (начало)
- •2.1. Необходимость инфологического моделирования
- •2.1.1. Виды ограничений целостности
- •2.1.2. Причины, приводящие к нарушению ограничений целостности
- •2.2. Описание объектов и их свойств
- •Тема 3. Инфологическое моделирование (окончание)
- •3.1. Описание связей между объектами.
- •3. 2. Описание сложных объектов
- •Вопросы для самоконтроля
- •Тема 4. Даталогическое проектирование
- •4.1. Общие сведения
- •4.2. Подход к даталогическому проектированию
- •4.3. Определение состава бд
- •4.4. Разновидности даталогических моделей
- •Вопросы для самоконтроля
- •Тема 5. Реляционная даталогическая модель базы данных
- •5.1. Основные понятия
- •5.2. Цели проектирования рбд
- •5.2.1. Возможность хранения всех необходимых данных в бд
- •5.2.2. Исключение избыточности данных
- •5.2.3. Сведение числа хранимых в бд отношений к минимуму
- •5.2.4. Нормализация отношений
- •Вопросы для самоконтроля
- •Тема 6. Метод проектирования реляционной базы данных на основе илм
- •Вопросы для самоконтроля
- •Тема 7. Пример проектирования реляционной базы данных на основе илм
- •7.6. Определение состава бд
- •7.7. Определение отношений, включаемых в бд
- •7.8. Описание логической структуры бд на языке субд (схема бд)
- •7.9. Сравнение спроектированной рбд с однотабличной бд
- •Вопросы для самоконтроля
- •Раздел 3. Описание информационных потребностей пользователей базы данных. Тема 8. Информационные потребности пользователей базы данных.
- •8.1. Типы и языки запросов
- •8.2. Реляционная алгебра (алгебра отношений)
- •8.2.1. Проекция
- •8.2.2. Выборка
- •8.2.3. Соединение
- •8.2.4. Объединение
- •8.2.5. Пересечение
- •8.2.6. Вычитание
- •8.2.7. Умножение
- •8.2.8. Деление
- •8.3. Примеры запросов на реляционном языке
- •Вопросы для самоконтроля
- •Раздел 4. Использование языкаSql для работы с базами данных. Тема9. Структурированный язык запросов sql
- •9.1. Стандарт и разновидности языка sql
- •9.2. Краткое введение в sql
- •Тема 10. Основные элементы языка sql. Использование языка sql для выборки данных
- •10.1. Оператор select
- •Тема 11. Отбор строк из таблиц. Условия поиска строк
- •Вопросы для самоконтроля
- •Тема 12. Сортировка таблиц
- •Тема 13. Использование псевдонимов для обозначения таблиц базы данных. Самосоединение таблиц. Итоговые запросы и агрегатные функции
- •Вопросы для самоконтроля
- •Тема 14. Запросы с группировкой
- •Тема 15. Вложенные запросы
- •Вопросы для самоконтроля
- •Тема 16. Изменение данных в базе данных
- •16.1. Корректировка таблиц бд
- •16.2. Создание объектов бд
- •16.3. Создание представлений
- •Вопросы для самоконтроля
- •Рекомендуемая литература
Тема 4. Даталогическое проектирование
4.1. Общие сведения
Цель даталогического проектирования заключается создании ДЛМ, которая отображает логические связи между элементами данных безотносительно к их смысловому содержанию и среде хранения. Эта модель строится в терминах информационных единиц, предусмотренных в конкретной СУБД. На рисунке 4.1. показана последовательность разработки ДЛМ.
Рис.4.1. Последовательность разработки ДЛМ:
Д1- документация по СУБД; Д2 … Дi- документация по средствам проектирования; U1- набор допустимых даталогических конструкций; U2- операторы ЯОД; U3- ограничения, налагаемые СУБД на ДЛМ; U4- возможности физической организации данных; П- перечень хранимых показателей ( атрибутов); ДЛМ- даталогическая модель; ИЛМ- инфологическая модель; S1- средства проектирования.
Любая СУБД оперирует с допустимыми для нее логическими единицами данных, а также допускает использование определенных правил композиции логических структур более высокого уровня и составляющих информационных единиц более низкого уровня. Кроме того, многие СУБД накладывают количественные и иные ограничения на структуру БД. Поэтому прежде чем приступить к построению ДЛМ, необходимо детально изучить особенности СУБД, определить факторы, влияющие на выбор проектного решения, ознакомиться с существующими методиками проектирования, а также провести анализ имеющихся средств автоматизации проектирования, оценить возможность и целесообразность их использования.
Хотя даталогическое проектирование является проектированием логической структуры БД, на него оказывают влияние возможности физической организации данных, представляемые конкретной СУБД. Поэтому знание особенностей физической организации данных может быть полезным при проектировании логической структуры.
Логическая структура БД, а также сама заполненная данными БД являются отображением реальной ПО. Поэтому на выбор проектных решений самое непосредственное влияние оказывает специфика ПО, отраженная в ИЛМ.
Результатом даталогического проектирования является описание логической структуры БД на ЯОД. В спроектированной логической структуре БД должны быть определены все информационные единицы и связи между ними, заданы имена информационных единиц, их тип и количественные характеристики ( например, длина поля).
4.2. Подход к даталогическому проектированию
Процесс проектирования БД предусматривает предварительную классификацию объектов ПО, систематизированное представление информации об объектах и связях между ними в ИЛМ.
На начальных этапах даталогического проектирования должен быть определен состав БД.
При проектировании логической структуры БД осуществляются преобразование исходной ИЛМ в модель данных, поддерживаемую конкретной СУБД, и проверка адекватности полученной ДЛМ отображаемой ПО.
Для любой ПО существует множество вариантов проектных решений ее отображения в ДЛМ. Методика проектирования должна обеспечивать выбор наиболее подходящего проектного решения.
Минимальная логическая единица данных для всех СУБД семантически одинакова и соответствует либо идентификатору объекта, либо свойству объекта или процесса.
Связи между объектами ПО, отраженные в ИЛМ, могут отображаться в ДЛМ либо посредством совместного расположения соответствующих им информационных элементов, либо путем объявления связи между ними. Не все виды связей, существующие в ПО, могут быть непосредственно отображены в конкретной ДЛМ. Так, многие СУБД не поддерживают непосредственно степень связь N:M между объектами. В этом случае в ДЛМ вводится дополнительный вспомогательный элемент, отображающий эту связь.
Следует иметь в виду, что связи, имеющиеся в ПО и отраженные в ИЛМ, могут быть представлены не только посредством структуры БД, но и программным путем. Например, при отображении обобщенных объектов можно не выделять подклассы на уровне логической структуры БД, а предусмотреть выделение подклассов программным путем при обработке хранимых данных.
Принимаемое проектное решение зависит не только от специфики отображаемой ПО, но и от характера обработки информации, хранимой в БД. Например, рекомендуется хранить вместе информацию, часто обрабатываемую совместно, и, наоборот, разделять по разным файлам информацию, не использующуюся одновременно. Информацию, используемую часто, и информацию, частота обращения к которой мала также следует хранить в разных файлах.