Файл: Базы данных проектирование бд жизненный цикл базы данных.ppt
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.12.2023
Просмотров: 70
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
БАЗЫ ДАННЫХ
ПРОЕКТИРОВАНИЕ БДЖизненный цикл базы данных
- Предварительное планирование
Определение границы использования БД
Состав пользователей
Сбор и анализ требований пользователей
описание предметной области процесс документооборота описание потоков информации и форм документов (исходную и генерируемую документацию);
описание объектов предметной области и связей между ними;
Сбор и анализ предметной области
описание потребностей пользователей:
перечень запросов и отчетов;
частота;
режим - диалоговый или пакетный алгоритмические связи показателей, формулы для их расчетов;
ограничения целостности (условия контроля данных на правильность и непротиворечивость)
Предварительное планирование
Оценка ресурсов
(программное, техническое, кадры)
Расчет стоимости проекта (окупаемость)
Описание предметной области
естественный язык,
Недостатки: громоздкость и неоднозначность
Описание предметной области
Общежитие института используется для проживания студентов. При поселении в общежитие студент заполняет карточку, в которой он сообщает сведения о себе:фио, № паспорта, дата рождения, адрес прописки, контактный телефон, номер группы. В общежитие есть комнаты, в которых могут проживать от 2-3 человека. Оплата производится в первых числах текущего месяц.
В общежитии есть инвентарь, которым могут пользоваться студенты за определенную плату. Инвентарь берется на срок и оплачивается при получении инвентаря.
Задание
1. Разработать таблицы, указав типы данных, ограничения, выдачу сообщений о некорректном вводе, создание списков для атрибутов, подстановку данных для подчиненных таблиц
2. Создать удобные формы для ввода исходных данных с обоснованием выбора вида формы
3. Система должна обеспечить выдачу следующих запросов( использовать макросы)
– (параметр № комнаты)свободные номера в комнатах общежития
– (параметр №паспорта)задолженность по оплате конкретного студента
– (параметр №паспорта)наличие инвентаря, взятого студентом
– (параметр №паспорта)запрос на изменение: переселение в другую комнату студента (макрос)
– запросы на удаление: выселение студента и сдача инвентаря
4. Система должна обеспечить выдачу следующих отчетов:
- (параметр дата) список должников на конкретную дату
– перечень комнат с указанием студентов проживающих в них
– печать квитанции на оплату с указанием фио студента, стоимости, срока оплаты, суммы, № комнаты, типа комнаты, даты оплаты
– (параметр №паспорта)запрос на изменение: переселение в другую комнату студента (макрос)
– запросы на удаление: выселение студента и сдача инвентаря
4. Система должна обеспечить выдачу следующих отчетов:
- (параметр дата) список должников на конкретную дату
– перечень комнат с указанием студентов проживающих в них
– печать квитанции на оплату с указанием фио студента, стоимости, срока оплаты, суммы, № комнаты, типа комнаты, даты оплаты
Жизненный цикл базы данных
1 Концептуальное проектирование
2 Логическое проектирование
3 Физическое проектирование.
4 Тестирование. Цель – обнаружение ошибок, проверка на соответствие требованиям пользователей.
5 Эксплуатация. Защита БД. Поддержка работоспособности БД.
Цель концептуального проектирования
Результаты анализа предметной области должны быть отражены в простом и наглядном виде:
1.Концептуальное проектирование
Разработка осуществляется без привязки к конкретной модели данных.
Результатом концептуального проектирования – инфологическая модель предметной области (семантическая модель) в графическом представлении (в виде диаграмм) предметной области.
Для разработки диаграмм используются различные абстрактные языки разработки:
UML (UML и IDEF применяются и при проектировании бизнес-процессов)
Методология IDEF1 разработана Тимоти Рэмей на основе ER- подхода и доработана до расширенной версии IDEF1X
IDEF1X - современное средство (Integration DEFinition for information modeling extended).
нотации ER-диаграмм (Чена, Мартина, Баркера ).
.
ERwin (Logic Works) - для создания концептуальных и логических схем баз данных. Можно редактировать наборы данных, представляя их в виде таблиц, разрабатывать структуры баз данных, синхронизировать модели, скрипты и БД, настраивать шаблоны, выводить рабочую информацию в виде отчетов, строить удобные и понятные диаграммы, отображающие различные процессы в системе и взаимосвязи между ними;
S-Designor (SDP) - для проектирования структуры реляционных БД. Он создает модели баз данных в два этапа - выстраивая концептуальную модель и затем преобразуя ее в физическую, причем в данном процессе разработки возможен как прямой, так и обратный переход между моделями. Данный инструмент позволяет проектировать базы данных под различные СУБД, в том числе под Oracle и MySQL;
.
DataBase Designer (ORACLE) - позволяет анализировать предметную область выполнять программирование и проектирование, проводить оценку и тестирование, осуществлять сопровождение, обеспечивать качество, управлять конфигурацией и проектом, разрабатывать и анализировать требования к информационной системе
Oracle DataModeler. Для обучения он доступен по условно-бесплатной лицензии
DESIGN/IFEF, Prokit * WorkBench, Power Designer,
Чаще всего программные коды в CASE-технологиях пишутся на языке SQL;
концептуальное проектирование - построение обобщенной модели базы данных ( описанием объектов и связей между ними);
логическое проектирование - создание схемы базы данных с учетом специфики конкретной модели данных без привязки к конкретной СУБД. (для РМД ЛМ БД будет содержать набор таблиц и связей );
физическое проектирование - построение схемы базы данных под конкретную СУБД. (учитываются ограничения на именование объектов базы данных, ограничения на определенные типы данных, физические условия хранения данных в БД (разделение по файлам и устройствам), возможность доступа к БД.
Инфологические модели
Концептуальное проектирование
1.Функциональный подход
2.Предметный подход
3.Использование метода сущность-связь
Метод сущность-связь
Сколько будет отношений ?
Какие атрибуты они будут содержать?
Как связаны некоторые отношения?
Проект определяет функционирование БД
ЕR – модель Сущность - связь П. Чен 1976 г. Основные понятия
Сущность (essence)– объект, информация о котором хранится в БД (базовые, зависимые)
Атрибут- свойство (характеристика) сущности (идентифицирующие и описательные)
Связь(relation) ассоциация между сущностями. Название связи обычно представляется глаголом (определяется степень, обязательность)
Каждый тип сущности представляется в виде прямоугольника
Атрибуты или свойства (характеристики) помещаются внутри прямоугольника
Имена ключевых атрибутов выделяются
Связь отображается виде ромба с именем связи внутри
Пример ER диаграммы
Степень связи: 1:1, 1:M, M:M
Преподаватель Дисциплина
Сущности, объединяемые связью, называются участниками.
Таб. №
Фамилия
Имя
Должность
Код_дисциплины
Наименование
Семестр
Отчётность
Ведет
Пример:
ПРЕПОДАВАТЕЛЬ ВЕДЕТ ДИСЦИПЛИНУ,
ПРЕПОДАВАТЕЛЬ РАБОТАЕТ НА КАФЕДРЕ
Имя связи должно отражать смысл отношения между объектами
Практическое занятие
Избыточность данных
.
| № сотр | ФИО | Должность | Оклад | №_ отдела | Кор. | Теле фон |
| 21 | Иванов | менеджер | 40000 | 5 | 2 | 111-11-12 |
| 37 | Петров | инженер | 40000 | 3 | 1 | 111-11-11 |
| 14 | Сидоров | программист | 70000 | 3 | 1 | 111-11-11 |
| 09 | Миронов | менеджер | 30000 | 7 | 3 | 111-11-13 |
| 05 | Федоров | зав . отд | 150000 | 3 | 1 | 111-11-11 |
| 41 | Иванов | секретарь | 20000 | 5 | 2 | 111-11-12 |
ИЗБЫТОЧНОСТЬ ДАННЫХ И АНОМАЛИЯ ОБНОВЛЕНИЯ
SСотрудники отделов = (№_сотр,ФИО. должность, Оклад,№_отд. корпус, телефон)
Таблица содержит избыточные данные:
Все поля, связанные с № отдела повторяются - корпус, телефон
Если в отношениях содержатся избыточные данные, то возникает проблемы с модификацией, вставкой и удалением информации из отношения.
Вставка
При добавлении новой информации - в данном примере сотрудники существующих отделов нужно точно повторить информацию, связанную с № отдела (корпус, телефон).
В противном случае данные будут противоречивы, (т е один отдел может находится в разных корпусах или иметь другой телефон)
СУБД не сможет контролировать эти ошибки.
Удаление
при удалении записи, содержащей сведения о сотруднике (Миронове удалятся сведения и о 7 отделе, который больше не фигурирует ни в одной записи, и при появлении нового сотрудника 7 отдела их придется искать в бумажных документах)
Обновление
изменение номера телефона 3 отдела придется производить в 3 записях, если будет пропущена хотя бы одна запись с таким же номером отдела, то данные будут противоречивы
Вывод
Таблица 1 содержит повторяющиеся избыточные данные, приводящие к аномалии обновления.
Для решения этой проблемы применяется декомпозиция таблицы, те она делится на две таблицы.
Возможно деление исходной таблицы и на большее число
Таблица 2 Сотрудники
| № сотр | ФИО | должность | Оклад | |
| 21 | Иванов | менеджер | 200 | |
| 37 | Петров | инженер | 100 | |
| 14 | Сидоров | программист | 1000 | |
| 09 | Степанов | менеджер | 400 | |
| 05 | Федоров | зав . отд | 1500 | |
| 41 | Иванов | секретарь | 200 |
Таблица 3 Отделы
| №_отд | корпус | телефон |
| 3 | 1 | 111-11-11 |
| 5 | 2 | 111-11-12 |
| 7 | 3 | 111-11-13 |
Процесс декомпозиции имеет 2 свойства
Соединение без потерь. Восстановление исходного отношения соединением отношений после декомпозиции
Сохранение зависимостей, которые позволят сохранять ограничения, наложенные на исходное отношение
Золотое правило проектировщика
Одинаковых атрибутов в разных объектах не может быть
Студент Группа
Код
Фио студента
Год поступления
Факультет
Номер группы
Староста
Факультет
Специальность
Состоит