Этапы проектирования базы данных. концептуальный, логический и физический уровни проектирования — студенческий портал

Суть проектирования баз данных (БД), как и любого другого процесса проектирования, в создании описания новой, прежде не существовавшей в таком виде системы, которая при её реализации способна предполагаемо функционировать в соответствующих условиях. Из этого следует, что этапы проектирования базы данных должны последовательно и логически связано отражать суть этого процесса.

Далее проектировщик, уже имеющий определённые представления о том, что ему нужно создать, уточняет предположительно решаемые приложением задачи, формирует их список (особенно, если в проектной разработке большая и сложная БД), уточняет последовательность решения задач и производит анализ данных. Такой процесс – тоже этапная проектная работа, но обычно в структуре проектирования эти шаги поглощаются этапом концептуального проектирования – этапом выделения объектов, атрибутов, связей.

Создание концептуальной (информационной модели) предполагает предварительное формирование концептуальных требований пользователей, включая требования в отношении приложений, которые могут и не быть сразу реализованным, но учёт которых позволит в будущем повысить функциональность системы.

Имея дело с представлениями объектов-абстракций множества (без указания способов физического хранения) и их взаимосвязями, концептуальная модель содержательно соответствует модели предметной области. Поэтому в литературе первый этап проектирования БД называется инфологическим проектированием.

Далее отдельным этапом (либо дополнением к предыдущему) следует этап формирования требований к операционной обстановке, где оцениваются требования к вычислительным ресурсам, способным обеспечить функционирование системы.

Соответственно, чем больше объем проектируемой БД, чем выше пользовательская активность и интенсивность обращений, тем выше требования предъявляются к ресурсам: к конфигурации компьютера к типу и версии операционной системы.

Например, многопользовательский режим работы будущей базы данных требует сетевого подключения с использованием операционной системы, соответствующей многозадачности.

После этого концептуальную модель необходимо перенести в совместимую с выбранной системой управления модель данных.

Но нередко это сопряжено с внесением поправок и изменений в концептуальную модель, поскольку не всегда взаимосвязи объектов между собой, отражённые концептуальной моделью, могут быть реализованы средствами данной СУБД.

Это обстоятельство определяет возникновение следующего этапа – появления обеспеченной средствами конкретной СУБД концептуальной модели. Данный шаг соответствует этапу логического проектирования (создания логической модели).

• Наконец, финальным этапом проектирования БД становится физическое проектирование – этап увязки логической структуры и физической среды хранения.
• Таким образом, основные этапы проектирования в детализированном виде представлены этапами:

• инфологического проектирования,
• формирования требований к операционной обстановке
• выбора системы управления и программных средств БД,
• логического проектирования,
• физического проектирования

Инфологическое проектирование

Идентификация сущностей составляет смысловую основу инфологического проектирования. Сущность здесь – это такой объект (абстрактный или конкретный), информация о котором будет накапливаться в системе.

В инфологической модели предметной области в понятных пользователю терминах, которые не зависят от конкретной реализации БД, описывается структура и динамические свойства предметной области. Но термины, при этом берутся в типовых масштабах.

То есть, описание выражается не через отдельные объекты предметной области и их взаимосвязи, а через:

• описание типов объектов,
• ограничения целостности, связанные с описанным типом,
• процессы, приводящие к эволюции предметной области – переходу её в другое состояние.

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

Поскольку использование метода «сущность-связь» является комбинированным способом проектирования на данном этапе, он чаще других становится приоритетным.

Локальные представления при методическом разделении должны, по возможности, включать в себя информацию, которой бы хватило для решения обособленной задачи или для обеспечения запросов какой-то группы потенциальных пользователей. Каждая из этих областей содержит порядка 6-7 сущностей и соответствует какому-либо отдельному внешнему приложению.

Зависимость сущностей отражается в разделении их на сильные (базовые, родительские) и слабые (дочерние). Сильная сущность (например, читатель в библиотеке) может существовать в БД сама по себе, а слабая сущность (например, абонемент этого читателя) «привязывается» к сильной и отдельно не существует.

Следует разделять понятия «экземпляр сущности» (объект, характеризующийся конкретными значениями свойств) и понятие «тип сущности» – объект, для которого характерно общее имя и список свойств.

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

• идентифицирующими (с уникальным значением для сущностей этого типа, что делает их потенциальными ключами) или описательными;
• однозначными или многозначными (с соответствующим количеством значений для экземпляра сущности);
• основными (независимыми от остальных атрибутов) или производными (вычисляемыми, исходя из значений иных атрибутов);
• простыми (неделимыми однокомпонентными) или составными (скомбинированными из нескольких компонентов).

После этого производится спецификация атрибута, спецификация связей в локальном представлении (с разделением на факультативные и обязательные) и объединение локальных представлений.При числе локальных областей до 4-5 их можно объединить за один шаг. В случае увеличения числа, бинарное объединение областей происходит в несколько этапов.

В ходе этого и других промежуточных этапов находит своё отражение итерационная природа проектирования, выражающаяся здесь в том, что для устранения противоречий необходимо возвращаться на этап моделирования локальных представлений для уточнения и изменения (например, для изменения одинаковых названий семантически разных объектов или для согласования атрибутов целостности на одинаковые атрибуты в разных приложениях).

Выбор системы управления и программных средств БД

• типа модели данных и её соответствие потребностям предметной области,
• запас возможностей в случае расширения информационной системы,
• характеристики производительности выбранной системы,
• эксплуатационная надёжность и удобство СУБД,
• инструментальная оснащённость, ориентированная на персонал администрирования данных,
• стоимость самой СУБД и дополнительного софта.

Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.

Логическое проектирование БД

Логическая структура БД должна соответствовать логической модели предметной области и учитывать связь модели данных с поддерживаемой СУБД. Поэтому этап начинается с выбора модели данных, где важно учесть её простоту и наглядность.

Предпочтительнее, когда естественная структура данных совпадает с представляющей её моделью. Так, например, если в данные представлены в виде иерархической структуры, то и модель лучше выбирать иерархическую.

Однако на практике такой выбор чаще определяется системой управления БД, а не моделью данных.

Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.

По завершению этапа должны быть сформированы схемы баз данных обоих уровней архитектуры (концептуального и внешнего), созданные на языке определения данных, поддерживаемых выбранной СУБД.

• либо с помощью восходящего подхода, когда работа идёт с нижних уровней определения атрибутов, сгруппированных в отношения, представляющие объекты, на основе существующих между атрибутами связей;
• либо с помощью обратного, нисходящего, подхода, применяемого при значительном (до сотен и тысяч) увеличении числа атрибутов.

Второй подход предполагает определение ряда высокоуровневых сущностей и их взаимосвязей с последующей детализацией до нужного уровня, что и отражает, например, модель, созданная на основе метода «сущность-связь». Но на практике оба подхода, как правило, комбинируются.

Физическое проектирование БД

На следующем этапе физического проектирования БД логическая структура отображается в виде структуры хранения БД, то есть увязывается с такой физической средой хранения, где данные будут размещены максимально эффективно. Здесь детально расписывается схема данных с указанием всех типов, полей, размеров и ограничений. Помимо разработки индексов и таблиц, производится определение основных запросов.

Построение физической модели сопряжено с решением во многом противоречивых задач:

1. задачи минимизации места хранения данных,
2. задачи достижения целостности, безопасности и максимальной производительности.

Вторая задача вступает в конфликт с первой, поскольку, например:

• для эффективного функционирования транзакций нужно резервировать дисковое место под временные объекты,
• для увеличения скорости поиска нужно создавать индексы, число которых определяется числом всех возможных комбинаций участвующих в поиске полей,
• для восстановления данных будут создаваться резервные копии базы данных и вестись журнал всех изменений.

Всё это увеличивает размер базы данных, поэтому проектировщик ищет разумный баланс, при котором задачи решаются оптимально путём грамотного размещения данных в пространстве памяти, но не за счёт средств защиты базы дынных, куда входит как защита от несанкционированного доступа, так и защита от сбоев.

Для завершения создания физической модели проводят оценку её эксплуатационных характеристик (скорость поиска, эффективность выполнения запросов и расхода ресурсов, правильность операций). Иногда этот этап, как и этапы реализации базы данных, тестирования и оптимизации, а также сопровождения и эксплуатации, выносят за пределы непосредственного проектирования БД.

Отзывы, комментарии и обсуждения

Источник: https://finswin.com/projects/proektirovanie/ehtapy-bazy-dannyh.html

Обзор современных методов проектирования баз данных

В настоящее время использование баз данных (БД) и информационных систем стало обязательным элементом осуществления деятельности каждой организации или предприятия.

Проекты, в рамках реализации которых выполняется обработка данных, представляют собой немалую часть всех проектов в области информационных технологий. В процессе создания таких систем решаются задачи проектирования баз данных различных типов.

Решение таких задач означает повышение степени вероятности того, что проектируемая информационная система будет отвечать определенным функциональным и информационным требованиям с учетом заданных ограничений.

В связи с этим большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов.

Основными подходами к проектированию систем БД являются восходящий метод и нисходящий метод проектирования. Суть первого способа заключается в структурном проектировании снизу—вверх. В данном процессе на основе описания частей осуществляется попытка получения целого, адекватно отображающего предметную область.

Этапы проектирования БД методом «восходящего» проектирования представлены на рисунке 1.

При использовании восходящего подхода на первом этапе происходит выявление свойств объектов (атрибутов сущностей) предметной области. Проводится анализ связей между свойствами, на основании которого свойства объединяются в таблицы (реляционные отношения).

Рисунок 1. Этапы проектирования БД методом «восходящего» проектирования

Во избежание различных аномалий, которые могут произойти при добавлении, обновлении или удалении данных из-за их избыточности, следует провести процесс нормализации каждой схемы отношения.

Отношения должны быть преобразованы к виду, отвечающему требованиям 3НФ.

В связи с большим количеством операций по нормализации метод восходящего проектирования также носит второе название – метод нормализации.

«Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости» [2].

Для успешного проведения нормализации (до 3НФ) необходимо выполнить ряд операций, представленных на рисунке 2. На первом этапе нормализации происходит сбор сырых данных, определение атрибутов.

Затем данные представляются в виде схем реляционных отношений. На втором этапе изучается семантика данных, определяется первичный ключ и функциональные зависимости между атрибутами.

Третий этап – это поиск и удаление транзитивных зависимостей.

Рисунок 2. Этапы нормализации

Восходящий метод проектирования применяют в распределенных БД при интеграции спроектированных локальных баз данных.

Для проектирования сложных БД преимущественно применяется нисходящий подход. При таком подходе работа начинается с подготовки моделей данных, содержащих несколько высокоуровневых сущностей и связей.  После этого производятся нисходящие уточнения низкоуровневых сущностей, связей и атрибутов, относящихся к ним.

Этапы проектирования БД методом «нисходящего» проектирования представлены на рисунке 3.

Нисходящий подход используется в концепции метода проектирования «сущность-связь».  В основе метода лежат три элемента: сущность, атрибут, связь.  Работа начинается с выявления сущностей и связей между ними.

В результате строится иерархическая схема, которая отражает состав и взаимоподчиненность отдельных функций.

Рисунок 3. Этапы проектирования БД методом «нисходящего» проектирования

Процесс построения баз данных методом «сущность-связь» включает в себя три этапа: концептуальное, логическое и физическое проектирование [1].

Концептуальное проектирование БД – это процесс, результатом которого является создание модели имеющейся информации. Модель строится вне зависимости от любых физических аспектов ее представления.

Такая модель данных формируется на основе информации, определенной в перечне требований пользователей. Особенности физической реализации (тип СУБД, язык программирования, тип вычислительной платформы и т.д.

) на данном этапе не учитываются.

На этапе логического проектирования БД происходит выбор модели организации данных, на основе которой создается модель используемой информации. Далее в концептуальную модель вносятся изменения и дополнения, и происходит преобразование в логическую модель данных. Созданная модель должна учитывать особенности организации данных в целевой СУБД (например, реляционная модель).

На данном этапе должна быть определена целевая СУБД (реляционная, сетевая, иерархическая или объектно-ориентированная), так как построение логической модели происходит с учетом выбранной модели организации данных.

С помощью метода нормализации происходит проверка правильности модели. Нормализация исключает избыточность данных, которая может привести к различным аномалиям в процессе обновления данных.

Физическое проектирование БД – это процесс, включающий в себя определение способов реализации и разработку описания конкретной реализации БД. В ходе данной стадии проектирования создается набор реляционных таблиц, определяется организация файлов и способы доступа к ним, а также анализируются ограничения целостности и разрабатываются средства защиты проектируемой БД.

• В таблице 1 приводится сравнение методов проектирования по нескольким критериям.
• Таблица 1.
• Сравнение методов проектирования БД

Критерии	Восходящее проектирование	Нисходящее проектирование
Степень описания семантики (смысла) предметной области	Низкая1	Высокая
Вероятность появления ошибок в последующей работе АИС	Высокая	Низкая2
Степень формализации процесса (возможность автоматизации процесса)	Отсутствует	Высокая
Объем трудозатрат при приведении ДЛМ БД к заданной НФ	Очень большой	Небольшой

1 – начальная модель не предусматривают возможность описания полного смысла предметной области.

2 – при условии качественного проектирования.

Каждый метод проектирования имеет свои преимущества и недостатки. При нисходящем проектировании элементы еще не определены, информация об их свойствах предположительна.

При восходящем проектировании элементы проектируются раньше системы, поэтому предположительный характер будут иметь требования к системе.

И в том, и в другом случае возможно несоответствие оптимальным техническим результатам.

Список литературы:

1. Дейт К.Дж. Введение в системы баз данных, 8-е издание.: Пер. с англ. – М.: Издательский дом «Вильяме», 2005. 1328с.
2. Описание основных приемов нормализации базы данных // Microsoft. [электронный ресурс] – Режим доступа. – URL: https://support.microsoft.com/ru-ru/help/283878/description-of-the-database-normalization-basics (дата обращения: 27.05.2017).

Источник: https://sibac.info/studconf/tech/liii/77651

Концептуальное и логическое проектирование базы данных — PDF Скачать Бесплатно

Подробнее

Подробнее
Подробнее

Подробнее

Подробнее

Подробнее

Подробнее

Подробнее

Подробнее

Подробнее

УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС ИНФОРМАТИКА. 10-11 КЛ. УГЛУБЛЁННЫЙ УРОВЕНЬ ФИОШИН М.Е, РЕССИН А.А., ЮНУСОВ С.М. Состав УМК 2 + + + =УМК Содержание и структура учебников 3 Содержание учебника — 10 кл. Содержание

Подробнее

Базы данных Лектор Азарченков А.А. Основные компоненты работы с данными База данных (БД) связанная совокупность структурированных данных, относящихся к определенному процессу или явлению, в конкретной

Подробнее

БАЗЫ ДАННЫХ (БД). СИСТЕМЫ УПРАВЛЕНИЯ БД Общие положения Цель любой информационной системы — обработка данных об объектах реального мира. В широком смысле слова база данных — это совокупность сведений о

Подробнее

Подробнее

УДК 004.65 Останкова Л. М. студент 1 курс, факультет «Информационные системы и технологии» ФГБОУ ВО Поволжский государственный университет телекоммуникаций и информатики России, г. Самара БАЗА ДАННЫХ И

Подробнее

Контроль знаний студентов по дисциплине «Модели данных»: Билет 1 1. Данные и ЭВМ. 2. Исходные сегменты Иерархическая модель. 3. Задача 1. Билет 2 1. Концепция баз данных. 2. Порожденные сегменты Иерархическая

Подробнее

Министерство образования и науки Российской Федерации Федеральное агентство по образованию Саратовский государственный технический университет Балаковский институт техники, технологии и управления СОЗДАНИЕ

Подробнее

Вариант 1 Выберите правильный вариант ответа. Возможен только один вариант правильного ответа. 1. Информационная система-это а) Любая система обработки информации б) Система обработки текстовой информации

Подробнее

1. Информация и данные 2. Основные понятия систем с базами данных Информационные компьютерные системы с базами данных это системы информационных, математических, программных, языковых, организационных

Подробнее

Практическая работа 12 Проектирование многотабличной базы данных, связывание таблиц в MS Access 1 Цель работы: научиться проектировать базу данных, проводить нормализацию базы данных. 2 Перечень технических

Подробнее

Метаданные теста Автор теста: Неверова Елена Григорьевна, старший преподаватель кафедры «ПИ» Название курса: Базы данных в информационных системах Предназначено для студентов специальности: очное отделение

Подробнее

Подробнее

1. ПОЯСНИТЕЛЬНАЯ ЗАПИСКА Целью изучения дисциплины «Банки и базы данных» является знакомство студентов с основами организации банков и баз данных, методами их проектирования, оптимизации и использования.

Подробнее

Министерство образования и науки РФ ФГОУ ВПО УРАЛЬСКИЙ ГОСУДАРСТВЕННЫЙ ЛЕСОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Институт экономики и управления КАФЕДРА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И МОДЕЛИРОВАНИЯ О.А. Карасева Базы данных

Подробнее

ОДОБРЕНА Предметной (цикловой) комиссией по спец.дисциплинам Разработана на основе Федерального государственного образовательного стандарта по специальности среднего профессионального образования 230401

Подробнее

Учебная дисциплина «Базы данных и управление ими» для студентов специальности 050501.65 «Профессиональное обучение» Лекция 17 МЕТОДЫ ОБЕСПЕЧЕНИЯ ЦЕЛОСТНОСТИ БАЗ ДАННЫХ Учебные вопросы: 1. Понятие и классификация

Подробнее

Виды моделей данных Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели

Подробнее

1 2 1 Цели и задачи дисциплины 1.1сформировать знания, умения и навыки для успешного использованиями СУБД в объеме пользователя, 1.2сформировать знания о принципах проектирования баз данных. 2 Требования

Подробнее

Модели данных и СУБД в гео Раздел 3. Структура современной СУБД и программное обеспечение работы с базами данных Лекция 4 Преподаватель Воробьёв Д.С. Структура современной СУБД и программное обеспечение

Подробнее

Подробнее

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ

Подробнее

Лекция 1 Базыданных Моисеев Михаил Юрьевич Вводнаялекция Целии задачи курса Получение навыков проектирования ИС Основные понятия и определения Базовые теории Практические навыки проектирования ИС Изучение

Подробнее

Дисциплина ОП.07 Основы проектирования баз данных Объем учебной дисциплины и виды учебной работы Направление подготовки 09.02.04 Информационные системы (по отраслям) Профиль технический Уровень подготовки

Подробнее

Модели данных Старший преподаватель Каф. Процессов управления и информационной безопасности Пермского государственного университета Неверов А.В. Понятие модели данных Модель данных это абстрактное, самодостаточное,

Подробнее

Источник: https://docplayer.ru/39230737-Konceptualnoe-i-logicheskoe-proektirovanie-bazy-dannyh.html

Проектирование фактографических БД: методы проектирования; концептуальное, логическое и физическое проектирование

⇐ ПредыдущаяСтр 6 из 17Следующая ⇒

База данных (БД) – совокупность хранящихся взаимосвязанных данных, организованных по определенным правилам. БД служат для хранения и поиска большого объема информации.

Особенностью фактографической информации является практическая очевидность (минимальная неопределённость, не требующая использования сложных или нечётких процедур) идентификации и интерпретации факта, как его имени, так и состояния.

То есть, в этом случае контекст (содержание) в достаточной степени определяется однозначно понимаемым объявлением о назначении базы данных и таким именованием полей данных, когда в качестве имени используется общепринятое, не зависящее от прикладных задач, имя свойства (и таким образом определяются характеристические признаки).

По характеру хранимой информации базы данных делятся на фактографические и документальные. В фактографических БД содержат краткие сведения об описываемых объектах, представленные в строго определенном формате. Например, в БД библиотеке о каждой книге хранятся библиографические сведения: год издания, автор, название и пр.

; в записной книжке школьника могут храниться фамилия, имена, даты рождения, телефоны, адреса друзей и знакомых. Примеры фактографических баз данных: БД книжного фонда библиотеки; БД кадрового состава учреждения.

Фактографические БД формируются двумя способами:

К настоящему времени выделились два подхода к созданию фактографических БД. Условно их можно назвать «исследовательским» и «библиотечным».

Наиболее характерная черта «исследовательских» БД – целенаправленный отбор информации для решения заранее сформулированной исследовательской задачи.

При «библиотечном» подходе сбор информации, как правило, непосредственно не связан с ее использованием. БД формируются преимущественно в ходе централизованной работы крупных научных и информационных центров и пополняются новыми данными без изменения уже существующей структуры информационного массива.

• Одним из наиболее важных этапов жизненного цикла базы данных является ее проектирование. Процесс проектирования может быть разделен на три этапа:
• • концептульаное проектирование;
• •логическое проектирование;
• •физическое проектирование.
• Концептуальное проектирование — это процесс конструирования информационной модели, не зависящей от каких-либо физических условий реализации.

Первый этап процесса проектирования базы данных называется концептуальным проектированием базы данных. Он заключается в создании концептуальной модели данных для анализируемой части предприятия. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей.

Концептуальное проектирование базы данных абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации.

При разработке концептуальная модель данных постоянно подвергается тестированию и проверке на соответствие требованиям пользователей. Созданная концептуальная модель данных предприятия является источником информации для этапа логического проектирования базы данных.

1. Этапами концептуального проектирования являются:
2. • определение типов сущностей;
3. • определение типов связей;
4. • определение атрибутов и связывание их с типами сущностей и связей;
5. • определение доменов атрибутов;
6. • определение потенциальных и первичных ключей;
7. • специализация или генерализация типов сущностей;
8. • обсуждение локальных концептуальных моделей данных с конечными пользователями;

• документирование.

Логическое проектирование — это процесс конструирования информационной модели на основе концептуальной модели.

Второй этап проектирования базы данных называется логическим проектированием базы данных. Его цель состоит в создании логической модели данных для исследуемой части предприятия.

Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных.

Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная модель).

В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки правильносги логической модели данных используется метод нормализации.

Нормализация гарантирует, что отношения, выведенные из существующей модели данных, не будут обладать избыточностью данных, способной вызвать нарушения в процессе обновления данных после их физической реализации.

Помимо всего прочего, логическая модель данных должна обеспечивать поддержку всех необходимых пользователям транзакций.

Созданная логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика физической базы данных средствами поиска компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования.

При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе.

• Этапы логического проектирования являются следующими:
• • преобразование концептуальной модели в логическую
• • проверка модели с помощью правил нормализации;
• • проверка модели в отношении транзакций пользователей;
• • определение требований поддержки целостности данных;
• • обсуждение логических моделей данных с конечными пользователями;
• • документирование.

Физическое проектирование— это процесс конструирования информационной модели с учетом конкретной используемой СУБД и прочих физических условий реализации (особенностей хранения данных, методов доступа и т.д.) на основе логической модели.

Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных.

Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области).

Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД.

Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.

1. Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. В случае реляционной модели данных под этим подразумевается следующее:
2. · создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
3. · определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;
4. · разработка средств защиты создаваемой системы.

Этапы концептуального и логического проектирования больших систем следует отделять от этапов физического проектирования. На это есть несколько причин.

• · Они связаны с совершенно разными аспектами системы, поскольку отвечают на вопрос, что делать, а не как делать.
• · Они выполняются в разное время, поскольку понять, что надо сделать, следует прежде, чем решить, как это сделать.
• · Они требуют совершенно разных навыков и опыта, поэтому требуют привлечения специалистов различного профиля.

⇐ Предыдущая12345678910Следующая ⇒

Рекомендуемые страницы:

Источник: https://lektsia.com/15xb96d.html

Проектирование базы данных на концептуальном уровне

• Основные понятия
• Концептуальный уровень проектирования – выявление и описание взаимосвязей между элементами данных, вытекающее из взаимосвязей в реальном мире предметной области.
• Сущности – личности, факты, объекты реального мира, имеющие отношение к некоторой проблемной области.
• Атрибуты – данные, описывающие сущности.
• Связи – взаимодействия между несколькими сущностями; связь может иметь атрибуты.
• Концептуальная модель –модель данных концептуального уровня.
• Концептуальная схема – графическое представление концептуальной модели.
• Задачи моделирования данных
• Цель построения модели: документирование требований к данным со стороны бизнес – процессов.
• Назначение модели: основа для создания физической базы данных.
• Преимущества правильно спроектированной базы:
• 1) минимальная избыточность данных;
• 2) максимальная целостность данных;
• 3) стабильность структуры БД;
• 4) эффективное совместное использование данных;
• 5) своевременность доступа к данным;
• 6) удобство и простота использования данных;
• 7) возможность разработки новых приложений без изменения структуры данных и др.

Альтернативный подход к проектированию базы данных можно назвать чисто «программистским», когда начинающий проектировщик базы данных быстро и приближенно проектирует базу под конкретную задачу аналогично разработке программ для работы с двумерными файлами. Однако, большинство разработчиков, использующих этот подход, быстро сталкивается с проблемами на этапе эксплуатации базы данных, в том числе: низкая производительность и нарушения целостности базы данных.

Можно утверждать, что правильный проект базы данных не может быть быстро составлен новичками. От проектировщика требуется знание формализованных подходов к сбору требований к данным, обнаружению и идентификации логических объектов и элементов данных. Приобретение мастерства и изучение всех нюансов может занять много времени.

Сущности

Сущность – это человек, место, предмет, понятие или событие, то есть то, что существует и что можно описать. Например: Студент, Преподаватель, Дисциплина, Заказчик, Товар и т.д.

Как выявить сущности?

Информация о сущностях используется в описании бизнес – процессов организации и представлена, как правило, именами существительными. Например: «обучение студентов», «продажа товаров» и т.п.

С чего начать?

После выявления сущностей необходимо четко определить их название.

Требования к имени сущности:имена должны быть стандартными, хорошо определенными и постоянными.

Правило задания имени сущности: имя сущности должно быть существительным в единственном числе, допускается сочетание с прилагательным. Желательно записывать имя заглавными буквами, например, СТУДЕНТ.

Проблема выбора имени: наличие синонимов, используемых разными категориями пользователей, например, СТУДЕНТ, УЧАЩИЙСЯ, ОБУЧАЕМЫЙ.

Решение проблемы: выбрать наиболее популярное название или принять волевое решение по этому поводу. Выбранное название должно быть единственным в базе данных.

При проектировании базы данных необходимо различать понятия «Сущность» и «Экземпляр сущности». Так, сущность СТУДЕНТ – это абстрактное понятие, а Иванов – это экземпляр сущности СТУДЕНТ.

1. Атрибуты
2. Атрибут – это характеристика или свойство сущности.
3. Можно выделить следующие разновидности атрибутов:
4. 1) идентифицирующие, то есть те, которые позволяют отличить один экземпляр сущности от другого, например, № студенческого билета; такие атрибуты являются потенциальными ключами сущности и должны быть неизменными;
5. 2) связывающие, то есть те, которые позволяют создать связи между сущностями;
6. 3) описывающие, то есть те, которые не относятся к первым двум разновидностям, например, Дата рождения.
7. Не существует точного правила, позволяющего отличить атрибут от сущности и наоборот.
8. Можно использовать следующие рекомендации:
9. 1) на основании знания бизнес – процессов выявить роли атрибутов (идентификация, связывание, описание);

2) экземпляры атрибутов, как правило, элементарны по своей природе, то есть атрибут представляет собой единичный факт, который в бизнес – процессах не раскладывается на составные части; например, ФИО как атрибут сущности СТУДЕНТ является не лучшим решением, т.к. раскладывается на составные части, которые в бизнес – процессах могут рассматриваются отдельно, например, поздравление всех Татьян с Татьяниным днем.

Соглашения для имен атрибутов могут быть разными в разных организациях, например, ИмяСтудента или имя_студента и т.п.

Существуют общепринятые сокращения для имен атрибутов, например, ID — идентификатор или ADDR – адрес и т.д.

При задании имен атрибутам необходимо избегать использования омонимов (ключ, замок и т.п.) и синонимов.

• После уточнения имен атрибутов необходимо определить множество допустимых значений каждого атрибута, используя для этих целей любые известные способы:
• — указание типа данных;
• — тип данных и диапазон;
• — использование классификаторов и кодификаторов;

— список допустимых значений и т.д.

Для каждого атрибутанеобходимо оценить возможность принимать неизвестное значение (NULL — значение).Например, сущность СТУДЕНТ, атрибут ЦветВолос. Как задать значение этого атрибута для студентки с неизвестным цветом волос или для лысого студента?

Ключи

Ключ состоит из одного или более атрибутов, значения которых однозначно идентифицируют экземпляр сущности, например, №Паспорта – ключ личности, по нему один экземпляр сущности ЛИЧНОСТЬ отличается от другого экземпляра.

Каждая сущность может иметь несколько ключей, но должна иметь по крайней мере один ключ. Такие ключи называются потенциальными ключами.

1. У каждой сущности есть один и только один первичный ключ, который выбирается из потенциальных ключей.
2. Критерии выбора первичного ключа:
3. — ключ должен гарантировать уникальность каждого экземпляра сущности;
4. — атрибуты, входящие в первичный ключ, не могут принимать NULL – значения;
5. — ключ должен быть неизменным, то есть неспособным и невосприимчивым к изменениям;
6. — значения первичных ключей должны задаваться внутри организации и не должны зависеть от внешних структур.

Например, сущность СЛУЖАЩИЙ. Атрибут №Паспорта является плохим кандидатом на роль первичного ключа, так как его значение зависит от внешних организаций и может быть изменено ими. Его значения находятся вне зоны внутреннего контроля. Лучшим решением является ТабельныйНомер, т.к. его значение присваивается внутри организации.

• Связи
• Связи моделируют отношения сущностей, возникающие в результате взаимодействия сущностей в ходе реализации бизнес – процессов.
• Типы связей:
• 1) унарные или рекурсивные – это связи между экземплярами одной и той же сущности, например, связь «подчиняться» моделирующая отношение «руководитель — подчиненный» на экземплярах сущности РАБОТАЮЩИЙ;
• 2) бинарные – это связи между двумя сущностями, например, связь «изучает» между сущностями СТУДЕНТ и ДИСЦИПЛИНА;
• 3) n – арные – это связи между более, чем двумя, сущностями, например, связь «обучает» между сущностями СТУДЕНТ, ПРЕПОДАВАТЕЛЬ и ДИСЦИПЛИНА.

Унарные и бинарные связи характеризуются мощностью и обязательностью. Характеристики задаются на каждом конце связи.

1. Мощность – это количество экземпляров сущности участвующих в каждом конкретном экземпляре связи.
2. В зависимости от мощности различают следующие виды связей:
3. 1) «один – к — одному«, например, связь «имеет» между сущностями СТУДЕНТ и МЕДИЦИНСКАЯ_КАРТА при условии, что учитываются только карты в конкретной поликлинике;
4. 2) «один – ко многим«, например, связь «состоит из» между сущностями СТУДЕНТ и ГРУППА при условии, что в базе будет храниться информация только об одной группе, в которой обучается студент;
5. 3) «многие – ко многим», например, связь «изучает» между сущностями СТУДЕНТ и ДИСЦИПЛИНА.

Обязательность – определяет обязательность наличия связи для каждого экземпляра сущности. Если существуют экземпляры сущности, для которых связь не задается, то для данной сущности связь является частичной.

В противном случае, связь называется обязательной или всюду определенной. Например, связь «состоит из» для сущности ГРУППА является обязательной, т.к. группа состоит хотя бы из одного студента и для каждой конкретной группы такая связь существует. Для сущности СТУДЕНТ данная связь является частичной, т.к.

существуют студенты, которые находятся в академическом отпуске и не могут быть приписаны к какой – либо группе.

Для связей также существуют соглашения по присваиванию имен.

Имя связи обычно задается глаголом. Для связи «многие – ко — многим» рекомендуется указывать два имени, например, СТУДЕНТ «изучает» ДИСЦИПЛИНУ и ДИСЦИПЛИНА «изучается» СТУДЕНТОМ, то есть связь именуется «изучает / изучается».

Классы и подклассы

Сущности проблемной области могут образовывать иерархии, построенные на основании отношений «класс — подкласс». Сущности, входящие в иерархию, связаны между собой отношением «один – ко — многим», при этом первичный ключ сущности – подкласса должен быть определен на подмножестве значений первичного ключа сущности – класса.

Источник: https://cyberpedia.su/14x14e6.html