Перечислите основные этапы проектирования реляционной бд кратко поясните содержание каждого этапа
Обновлено: 28.06.2024
План:
1 Этапы и принципы проектирования баз данных.
2 Жизненный цикл БД.
3 Подробнее об этапах проектирования и разработки БД и приложений
4 Запросы на выборку информации.
foreign key — внешний ключ.
ER-модель — Entity-Relationship model.
primary key — Первичный ключ.
Этапы проектирования БД
- исследование предметной области;
- анализ данных (сущностей и их атрибутов);
- определение отношений между сущностями
и определение первичных и вторичных (внешних) ключей.
В процессе проектирования определяется структура
реляционной БД
(состав таблиц, их структура и логические связи).
Структура таблицы определяется составом столбцов,
типом и длиной данных, ключами таблицы.
Сущность – любой конкретный или абстрактный объект
в рассматриваемой предметной области.
Сущности – это базовые типы информации, которые хранятся в БД
(в реляционной БД каждой сущности назначается таблица).
К сущностям могут относиться: студенты, клиенты, подразделения и т.д.
Экземпляр сущности и тип сущности — это разные понятия.
Понятие тип сущности относится к набору однородных личностей,
предметов или событий, выступающих как целое
(например, студент, клиент и т.д.).
Экземпляр сущности относится, например, к конкретной личности в наборе.
Типом сущности может быть студент,
а экземпляром – Петров, Сидоров и т. д.
этапы работы с БД
· создание структуры таблиц базы данных;
· ввод и редактирование данных в таблицах;
· обработка данных, содержащихся в таблицах;
· вывод информации из базы данных.
Жизненный цикл БД
ЖЦБД включает в себя следующие 9 основных этапов:
- планирование разработки базы данных;
Оценка экономической целесообразности и реализуемости
через анализ объема работ, ресурсов и стоимости проекта. - определение требований к системе;
определение диапазон действия приложения базы данных,
состав его пользователей и области применения. - сбор и анализ требований пользователей;
создать модель движения важных материальных объектов
и выясняем процесс документооборота. - проектирование базы данных:
- концептуальное проектирование базы данных;
- логическое проектирование базы данных;
- физическое проектирование базы данных;
- разработка приложений:
- проектирование транзакций;
- проектирование пользовательского интерфейса;
- физическая реализация; кодирование алгоритмов.
- загрузка данных;
На этом этапе пустые таблицы, предназначенные для
хранения информации, должны быть заполнены данными. - тестирование;
Для оценки завершённости приложения базы данных
выполняется тестирование приложения, работающего с БД. - эксплуатация и сопровождение
Основные действия, этого этапа наблюдение за созданной
системой и поддержка ее нормального функционирования.
Адаптация и модернизация под изменение предметной
области, создание дополнительных компонент
или модернизация самой БД.
Этапы проектирования и разработки БД
4 Проектирование базы данных
Полный цикл разработки базы данных включает концептуальное,
логическое и физическое ее проектирование.
Концептуальное проектирование базы данных
Первая фаза процесса проектирования базы данных заключается
в создании для анализируемой части предприятия концептуальной
модели данных.
Проектирование сложных баз данных с большим количеством
атрибутов осуществляется с использованием, нисходящего подхода.
Начинается с разработки моделей данных, которые содержат
несколько высокоуровневых сущностей и связей, затем работа
продолжается в виде серии нисходящих уточнений низкоуровневых
сущностей, связей и относящихся к ним атрибутов.
- Выделение локальных представлений, соответствующих обычно
относительно независимым данным. - Формулирование сущностей, описывающих локальную предметную
область проектируемой БД, и описание атрибутов, составляющих
структуру каждой сущности. - Выделение ключевых атрибутов.
- Спецификация связей между сущностями. Удаление избыточных
связей. - Анализ и добавление неключевых атрибутов.
- Объединение локальных представлений.
Созданная концептуальная модель данных предприятия является
источником информации для фазы логического проектирования
базы данных.
Логическое проектирование базы данных.
Логическая модель, отражает особенности представления
о функционировании предприятия одновременно многих типов
пользователей.
Концептуальное и логическое проектирование — это
итеративные процессы, которые включают в себя ряд уточнений,
продолжающиеся до тех пор, пока не будет получен наиболее
соответствующий структуре предприятия продукт.
Физическое проектирование базы данных
Целью проектирования на данном этапе является создание
описания СУБД-ориентированной модели БД.
Для реляционной модели данных под физическим
проектированием подразумевается:
- описание набора реляционных таблиц и ограничений для
них на основе информации логической модели данных; - определение конкретных структур хранения данных
и методов доступа к ним, обеспечивающих оптимальную
производительность системы с базой данных;
команда SELECT
Это наиболее часто используемая команда SQL.
Её назначение — выборка данных из БД
SELECT [DISTINCT|ALL ] < * | [fieldExpression [AS newName]>
FROM tableName [alias]
[WHERE condition][GROUP BY fieldName(s)] [HAVING condition]
[ORDER BY fieldName(s)]
В качестве предметной области выбрана деятельность фирмы по продаже автомобилей марки Toyota. Поставлена задача: упорядочить информацию о клиентах фирмы, ассортименте продукции и сформированных заказах.
Этапы 1-3 проектирования БД изучить теоретически, 4-5 выполнить практически.
1-й этап. Определение цели проектирования БД.
Проектируемая реляционная БД должна содержать структурированную информацию о клиентах, продаваемых автомобилях и заказах.
Проектируемая БД должна поддерживать выполнение, как минимум, следующих основных функций: ввод и обновление информации, просмотр и удаление.
2-й этап. Разработка информационно-логической модели предметной области.
Вся информация о предметной области может быть логично разделена на 3 таблицы:
Клиенты, Автомобили, Заказы.
При этом выполняются основные требования к содержанию таблиц:
1. Каждая таблица содержит информацию только на одну тему.
2. Информация в таблицах не дублируется.
3. Для связи между таблицами заданы первичные ключи, однозначно определяющие каждую запись в таблице.
Содержание базовых таблиц приведено ниже:
| Таблица Клиенты | Таблица Автомобили | Таблица Заказы |
| 1. Код клиента (ключ) | 2. Код модели (ключ) | 3. Код заказа (ключ) |
| 4. Фамилия | 5. Модель | 6. Код клиента |
| 7. Имя | 8. Мощность двигателя | 9. Код Модели |
| 10. Отчество | 11. Цвет | 12. Дата заказа |
| 13. Адрес | 14. Количество дверей | 15. Скидка, % |
| 16. Телефон | 17. Заводская цена | 18. Оплачено |
| 1. Издержки (транспортные, предпродажные) | ||
| 2. Специальная модель | ||
| 3. Дополнительное оснащение |
При разработке полей для каждой таблицы необходимо учитывать:
· Каждое поле должно быть связано с темой таблицы.
· Не включать в таблицу данные, которые являются результатом вычисления.
3-й этап. Определение отношений между таблицами.
Поскольку для проектируемой БД выполнены требования нормализации, между таблицами Клиенты-Заказы и Автомобили-Заказы могут быть установлены одно-многозначные отношения (1:∞), которые поддерживаются реляционной СУБД.
Связь между таблицами устанавливается с помощью ключей Код клиента и Код модели, которые в главных таблицах Клиенты и Автомобили являются первичными, а в таблице-связке Заказы – внешними.
4-й этап. Создание таблиц БД средствами СУБД MS Access.
4.1. Загрузить СУБД MS Access. Создать в рабочей папке файл БД, присвоив имя toyota. Заполнить свойства БД.
4.2. Выбрать в окне БД вкладку Таблицы.
4.3. Создать макет таблицы Автомобили в режиме Конструктора, используя нижеприведенные данные об именах полей, их свойствах и типах данных.
*Все поля, за исключением поля Другое оснащение, должны быть обязательными для заполнения (Свойство Обязательное поле: Да).
*Мастер подстановок позволяет создать для указанных полей список, из которого выбирается значение.
4.4. Перейти в режим Таблицы, сохранив созданный макет таблицы под именем Автомобили.
4.5. Добавить в таблицу Автомобили 3 записи:
| Код модели | 12580 | 12653 | 12651 |
| Модель | Corolla Liftback | Corolla CompactGT | Corolla CompactXL |
| Мощность | 69/90 | 100/139 | 90/135 |
| Цвет | Бутылочное стекло | Черный | Небесно-голубой |
| Количество дверей | 4 | 2 | 2 |
| Коробка передач | Автоматика | Ручная | Ручная |
| Обивка | Ткань | Кожа | Велюр |
| Другое оснащение | Радио/плейер, раздвижная крыша, лаковое покрытие “Металлик” | Радио/плейер, раздвижная крыша, алюмин. дворники | Электро-подъемник окон, раздвижная крыша |
| Заводская цена | 39200 | 41100 | 37900 |
| Транспортные издержки | 1200 | 975 | 1050 |
| Предпродажные издержки | 105 | 105 | 105 |
| Специальная модель | Нет | Да | Да |
4.6. Создать макет таблицы Клиенты в режиме Конструктора.
*Обязательные поля Код клиента, Фамилия, Страна.
| Имя поля | Тип данных | Описание | Свойства поля (определяют правила сохранения, отображения и обработки данных в поле) |
| Код клиента | Счетчик | Ключевое поле, уникальный номер клиента в БД | Индексированное поле: Да/Совпадения не допускаются Ключевое поле задается в меню Правка/Ключевое поле |
| Фамилия | Текст | Фамилия | Размер поля: 40, Индексированное поле: Да/Совпадения допускаются |
| Имя | Текст | Имя | Размер поля: 20, Индексированное поле: Да/Совпадения допускаются |
| Отчество | Текст | Отчество | Размер поля: 40, Индексированное поле: Да/Совпадения допускаются |
| Индекс | Числовой | Почтовый индекс | Размер поля: Длинное целое, Индексированное поле: Да/Совпадения допускаются |
| Страна | Текст | Название страны | Размер поля: 20, Индексированное поле: Да/Совпадения допускаются |
| Населенный пункт | Текст | Название населенного пункта | Размер поля: 40, Индексированное поле: Да/Совпадения допускаются |
| Почтовый адрес | Текст | Почтовый адрес | Размер поля: 50, Индексированное поле: Нет |
| Телефон | Текст | Контактный телефон | Размер поля: 20, Индексированное поле: Нет |
4.7. Добавить в таблицу Клиенты 3 записи. (Перейти в режим Таблицы, сохранив макет таблицы под именем Клиенты)
4.8. Создать в режиме Конструктора макет таблицы Заказы.
*Все поля, за исключением поля Скидка, являются обязательными для заполнения.
| Имя поля | Тип данных | Описание | Свойства поля (определяют правила сохранения, отображения и обработки данных в поле) |
| Код заказа | Счетчик | Ключевое поле, уникальный номер заказа | Индексированное поле: Да/Совпадения не допускаются Ключевое поле задается в меню Правка/Ключевое поле |
| Код модели | Числовой, *Мастер подстановок | Внешний ключ, для связи с таблицей Автомобили | Размер поля: Длинное целое Индексированное поле: Да, допускаются совпадения |
| Код клиента | Числовой, *Мастер подстановок | Внешний ключ, для связи с таблицей Клиенты | Размер поля: Длинное целое Индексированное поле: Да, допускаются совпадения |
| Дата заказа | Дата/время | Дата формирования заказа ДД.ММ.ГГ | Формат: Краткий формат даты Индексированное поле: Да/Совпадения допускаются |
| Скидка | Числовой | Размер скидки в % | Размер поля: Одинарное с плавающей точкой Формат: Процентный Условие на значение: Between 0 And 1 |
* Используя Мастер подстановок, сформировать для полей Код клиента и Код модели список выбора из таблиц Клиенты и Автомобили (сбросить флажок Скрыть ключевое поле).
4.9. Добавить 5 записей в таблицу Заказы.
5-й этап. Создание схемы данных БД (связей между таблицами).
5.1. Выполнить команду Схема данных из меню Сервис. В диалоговом окне Добавление таблицы последовательно добавить все три таблицы. Закрыть диалоговое окно.
5.2. Установить связь между таблицами Клиенты-Заказы, Автомобили-Заказы: выделить ключевое поле в главной таблице (Клиенты или Автомобили) и перетащить его на соответствующее поле таблицы-связки Заказы. Обеспечить целостность данных.
5.3. Сохранить макет схемы данных.
Контрольные вопросы
Перечислите основные этапы проектирования реляционной БД. Кратко поясните содержание каждого этапа.
Какие требования предъявляют к содержанию таблиц реляционной БД?
Приведите порядок создания макета таблицы в режиме Конструктора.
4. Понятия "ключевое поле". Какие бывают ключевые поля?
Для чего в каждой таблице задается первичный ключ? В чем различие между первичным и внешним ключом?
Порядок формирования схемы БД.
Порядок выполнения работы
В качестве предметной области выбрана деятельность фирмы по продаже автомобилей марки Toyota. Поставлена задача: упорядочить информацию о клиентах фирмы, ассортименте продукции и сформированных заказах.
Этапы 1-3 проектирования БД изучить теоретически, 4-5 выполнить практически.
1-й этап. Определение цели проектирования БД.
Проектируемая реляционная БД должна содержать структурированную информацию о клиентах, продаваемых автомобилях и заказах.
Проектируемая БД должна поддерживать выполнение, как минимум, следующих основных функций: ввод и обновление информации, просмотр и удаление.
2-й этап. Разработка информационно-логической модели предметной области.
Вся информация о предметной области может быть логично разделена на 3 таблицы:
Клиенты, Автомобили, Заказы.
При этом выполняются основные требования к содержанию таблиц:
1. Каждая таблица содержит информацию только на одну тему.
2. Информация в таблицах не дублируется.
3. Для связи между таблицами заданы первичные ключи, однозначно определяющие каждую запись в таблице.
Содержание базовых таблиц приведено ниже:
| Таблица Клиенты | Таблица Автомобили | Таблица Заказы |
| 1. Код клиента (ключ) | 2. Код модели (ключ) | 3. Код заказа (ключ) |
| 4. Фамилия | 5. Модель | 6. Код клиента |
| 7. Имя | 8. Мощность двигателя | 9. Код Модели |
| 10. Отчество | 11. Цвет | 12. Дата заказа |
| 13. Адрес | 14. Количество дверей | 15. Скидка, % |
| 16. Телефон | 17. Заводская цена | 18. Оплачено |
| 1. Издержки (транспортные, предпродажные) | ||
| 2. Специальная модель | ||
| 3. Дополнительное оснащение |
При разработке полей для каждой таблицы необходимо учитывать:
· Каждое поле должно быть связано с темой таблицы.
· Не включать в таблицу данные, которые являются результатом вычисления.
3-й этап. Определение отношений между таблицами.
Поскольку для проектируемой БД выполнены требования нормализации, между таблицами Клиенты-Заказы и Автомобили-Заказы могут быть установлены одно-многозначные отношения (1:∞), которые поддерживаются реляционной СУБД.
Связь между таблицами устанавливается с помощью ключей Код клиента и Код модели, которые в главных таблицах Клиенты и Автомобили являются первичными, а в таблице-связке Заказы – внешними.
4-й этап. Создание таблиц БД средствами СУБД MS Access.
4.1. Загрузить СУБД MS Access. Создать в рабочей папке файл БД, присвоив имя toyota. Заполнить свойства БД.
4.2. Выбрать в окне БД вкладку Таблицы.
4.3. Создать макет таблицы Автомобили в режиме Конструктора, используя нижеприведенные данные об именах полей, их свойствах и типах данных.
*Все поля, за исключением поля Другое оснащение, должны быть обязательными для заполнения (Свойство Обязательное поле: Да).
*Мастер подстановок позволяет создать для указанных полей список, из которого выбирается значение.
4.4. Перейти в режим Таблицы, сохранив созданный макет таблицы под именем Автомобили.
4.5. Добавить в таблицу Автомобили 3 записи:
| Код модели | 12580 | 12653 | 12651 |
| Модель | Corolla Liftback | Corolla CompactGT | Corolla CompactXL |
| Мощность | 69/90 | 100/139 | 90/135 |
| Цвет | Бутылочное стекло | Черный | Небесно-голубой |
| Количество дверей | 4 | 2 | 2 |
| Коробка передач | Автоматика | Ручная | Ручная |
| Обивка | Ткань | Кожа | Велюр |
| Другое оснащение | Радио/плейер, раздвижная крыша, лаковое покрытие “Металлик” | Радио/плейер, раздвижная крыша, алюмин. дворники | Электро-подъемник окон, раздвижная крыша |
| Заводская цена | 39200 | 41100 | 37900 |
| Транспортные издержки | 1200 | 975 | 1050 |
| Предпродажные издержки | 105 | 105 | 105 |
| Специальная модель | Нет | Да | Да |
4.6. Создать макет таблицы Клиенты в режиме Конструктора.
*Обязательные поля Код клиента, Фамилия, Страна.
| Имя поля | Тип данных | Описание | Свойства поля (определяют правила сохранения, отображения и обработки данных в поле) |
| Код клиента | Счетчик | Ключевое поле, уникальный номер клиента в БД | Индексированное поле: Да/Совпадения не допускаются Ключевое поле задается в меню Правка/Ключевое поле |
| Фамилия | Текст | Фамилия | Размер поля: 40, Индексированное поле: Да/Совпадения допускаются |
| Имя | Текст | Имя | Размер поля: 20, Индексированное поле: Да/Совпадения допускаются |
| Отчество | Текст | Отчество | Размер поля: 40, Индексированное поле: Да/Совпадения допускаются |
| Индекс | Числовой | Почтовый индекс | Размер поля: Длинное целое, Индексированное поле: Да/Совпадения допускаются |
| Страна | Текст | Название страны | Размер поля: 20, Индексированное поле: Да/Совпадения допускаются |
| Населенный пункт | Текст | Название населенного пункта | Размер поля: 40, Индексированное поле: Да/Совпадения допускаются |
| Почтовый адрес | Текст | Почтовый адрес | Размер поля: 50, Индексированное поле: Нет |
| Телефон | Текст | Контактный телефон | Размер поля: 20, Индексированное поле: Нет |
4.7. Добавить в таблицу Клиенты 3 записи. (Перейти в режим Таблицы, сохранив макет таблицы под именем Клиенты)
4.8. Создать в режиме Конструктора макет таблицы Заказы.
*Все поля, за исключением поля Скидка, являются обязательными для заполнения.
| Имя поля | Тип данных | Описание | Свойства поля (определяют правила сохранения, отображения и обработки данных в поле) |
| Код заказа | Счетчик | Ключевое поле, уникальный номер заказа | Индексированное поле: Да/Совпадения не допускаются Ключевое поле задается в меню Правка/Ключевое поле |
| Код модели | Числовой, *Мастер подстановок | Внешний ключ, для связи с таблицей Автомобили | Размер поля: Длинное целое Индексированное поле: Да, допускаются совпадения |
| Код клиента | Числовой, *Мастер подстановок | Внешний ключ, для связи с таблицей Клиенты | Размер поля: Длинное целое Индексированное поле: Да, допускаются совпадения |
| Дата заказа | Дата/время | Дата формирования заказа ДД.ММ.ГГ | Формат: Краткий формат даты Индексированное поле: Да/Совпадения допускаются |
| Скидка | Числовой | Размер скидки в % | Размер поля: Одинарное с плавающей точкой Формат: Процентный Условие на значение: Between 0 And 1 |
* Используя Мастер подстановок, сформировать для полей Код клиента и Код модели список выбора из таблиц Клиенты и Автомобили (сбросить флажок Скрыть ключевое поле).
4.9. Добавить 5 записей в таблицу Заказы.
5-й этап. Создание схемы данных БД (связей между таблицами).
5.1. Выполнить команду Схема данных из меню Сервис. В диалоговом окне Добавление таблицы последовательно добавить все три таблицы. Закрыть диалоговое окно.
5.2. Установить связь между таблицами Клиенты-Заказы, Автомобили-Заказы: выделить ключевое поле в главной таблице (Клиенты или Автомобили) и перетащить его на соответствующее поле таблицы-связки Заказы. Обеспечить целостность данных.
Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.
Невозможно создать БД без подробного ее описания, также как и невозможно сделать какое-либо сложное изделие без чертежа и подробного описания технологий его изготовления. Другими словами, нужен проект. Проектом принято считать эскиз некоторого устройства, который в дальнейшем будет воплощен в реальность. Процесс проектирования БД представляет собой процесс переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. Конечной целью проектирования является построение конкретной БД. Очевидно, что процесс проектирования сложен и поэтому имеет смысл разделить его на логически завершенные части – этапы.
При проектировании таблиц рекомендуется руководствоваться следующими основными принципами:
- Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация хранится только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и телефоны клиентов.
- Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если они содержатся в независимых друг от друга таблицах. Например, адреса и заказы клиентов лучше хранить в разных таблицах с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
- Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").
- База данных должна иметь первичный ключ. Это необходимо для того, чтобы СУБД могла связать данные из разных таблиц, например, данные о клиенте и его заказы.
Основные задачи проектирования баз данных:
- Обеспечение хранения в БД всей необходимой информации.
- Обеспечение возможности получения данных по всем необходимым запросам.
- Сокращение избыточности и дублирования данных.
- Обеспечение целостности базы данных.
Основные этапы проектирования баз данных:
Концептуальное (инфологическое) проектирование.
Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.
Чаще всего концептуальная модель базы данных включает в себя:
- описание информационных объектов или понятий предметной области и связей между ними.
- описание ограничений целостности, то есть требований к допустимым значениям данных и к связям между ними.
Инфологическую модель можно создавать с помощью нескольких методов и подходов:
Локальные представления при методическом разделении должны, по возможности, включать в себя информацию, которой бы хватило для решения обособленной задачи или для обеспечения запросов какой-то группы потенциальных пользователей. Каждая из этих областей содержит порядка 6-7 сущностей и соответствует какому-либо отдельному внешнему приложению.
Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:
- идентифицирующими (с уникальным значением для сущностей этого типа, что делает их потенциальными ключами) или описательными;
- однозначными или многозначными (с соответствующим количеством значений для экземпляра сущности);
- основными (независимыми от остальных атрибутов) или производными (вычисляемыми, исходя из значений иных атрибутов);
- простыми (неделимыми однокомпонентными) или составными (скомбинированными из нескольких компонентов).
После этого производится спецификация атрибута, спецификация связей в локальном представлении (с разделением на факультативные и обязательные) и объединение локальных представлений. При числе локальных областей до 4-5 их можно объединить за один шаг. В случае увеличения числа бинарное объединение областей происходит в несколько этапов.
В ходе этого и других промежуточных этапов находит своё отражение итерационная природа проектирования, выражающаяся здесь в том, что для устранения противоречий необходимо возвращаться на этап моделирования локальных представлений для уточнения и изменения (например, для изменения одинаковых названий семантически разных объектов или для согласования атрибутов целостности на одинаковые атрибуты в разных приложениях).
Логическое (даталогическое) проектирование.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Логическая структура БД должна соответствовать логической модели предметной области и учитывать связь модели данных с поддерживаемой СУБД. Поэтому этап начинается с выбора модели данных, где важно учесть её простоту и наглядность.
Предпочтительнее, когда естественная структура данных совпадает с представляющей её моделью. Так, например, если в данные представлены в виде иерархической структуры, то и модель лучше выбирать иерархическую. Однако на практике такой выбор чаще определяется системой управления БД, а не моделью данных. Поэтому концептуальная модель фактически транслируется в такую модель данных, которая совместима с выбранной системой управления БД.
Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.
По завершению этапа должны быть сформированы схемы баз данных обоих уровней архитектуры (концептуального и внешнего), созданные на языке определения данных, поддерживаемых выбранной СУБД.
Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:
- либо с помощью восходящего подхода, когда работа идёт с нижних уровней определения атрибутов, сгруппированных в отношения, представляющие объекты, на основе существующих между атрибутами связей;
- либо с помощью обратного, нисходящего, подхода, применяемого при значительном (до сотен и тысяч) увеличении числа атрибутов.
Физическое проектирование.
Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д.
На следующем этапе физического проектирования БД логическая структура отображается в виде структуры хранения БД, то есть увязывается с такой физической средой хранения, где данные будут размещены максимально эффективно. Здесь детально расписывается схема данных с указанием всех типов, полей, размеров и ограничений. Помимо разработки индексов и таблиц, производится определение основных запросов.
Построение физической модели сопряжено с решением во многом противоречивых задач:
- задачи минимизации места хранения данных,
- задачи достижения целостности, безопасности и максимальной производительности.
Вторая задача вступает в конфликт с первой, поскольку, например:
- для эффективного функционирования транзакций нужно резервировать дисковое место под временные объекты,
- для увеличения скорости поиска нужно создавать индексы, число которых определяется числом всех возможных комбинаций участвующих в поиске полей,
- для восстановления данных будут создаваться резервные копии базы данных и вестись журнал всех изменений.
Всё это увеличивает размер базы данных, поэтому проектировщик ищет разумный баланс, при котором задачи решаются оптимально путём грамотного размещения данных в пространстве памяти, но не за счёт средств защиты базы дынных, куда входит как защита от несанкционированного доступа, так и защита от сбоев.
Для завершения создания физической модели проводят оценку её эксплуатационных характеристик (скорость поиска, эффективность выполнения запросов и расхода ресурсов, правильность операций). Иногда этот этап, как и этапы реализации базы данных, тестирования и оптимизации, а также сопровождения и эксплуатации, выносят за пределы непосредственного проектирования БД.
Выбор системы управления и программных средств БД.
От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:
- типа модели данных и её соответствие потребностям предметной области,
- запас возможностей в случае расширения информационной системы,
- характеристики производительности выбранной системы,
- эксплуатационная надёжность и удобство СУБД,
- инструментальная оснащённость, ориентированная на персонал администрирования данных,
- стоимость самой СУБД и дополнительного софта.
Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.
Разработка эффективной базы данных состоит из нескольких этапов. Процесс разработки БД начинается с анализа требований. Проектировщик на этом этапе разработки должен найти ответы на следующие вопросы: какие элементы данных должны храниться, кто и как будет к ним обращаться.
На втором этапе создается логическая структура БД. Для этого определяют, как данные будут сгруппированы логически. Структура БД на этом этапе выражается в терминах прикладных объектов и отношений между ними.
На заключительном (третьем) этапе логическая структура БД преобразуется в физическую с учетом аспектов производительности. Элементы данных на этом этапе получают атрибуты и определяются как столбцы в таблицах выбранной для реализации БД СУБД.
Рассмотрим применение концепции реляционных баз данных на практике. Представим себе деятельность туристической фирмы. Очевидно, что для ее работы необходимо хранить и отслеживать определенный набор информации о клиентах данной турфирмы (туристах), о предлагаемых им турах, об оформлении и оплате путевок. Это можно делать в обычной бумажной тетради, но со временем поиск нужных записей и финансовая отчетность будут представлять собой довольно рутинную, длительную работу.
© 2022 Научная библиотека
Копирование информации со страницы разрешается только с указанием ссылки на данный сайт
Читайте также: