Алгоритм проектирования базы данных
В этом разделе студенту необходимо описать алгоритм проектирования базы данных, который состоит из 3-х частей:
- концептуальное проектирование;
- логическое проектирование;
- физическое проектирование.
Концептуальное проектирование
Концептуальное проектирование базы данных выполняется на основе развернутого технического задания на разработку программного продукта и начинается с создания концептуальной модели данных предприятия, которая является абсолютно независимой от таких деталей реализации, как целевая СУБД, особенности прикладных программ, используемый язык программирования, выбранная вычислительная платформа.
ER модель включает в себя описание информационных объектов, или понятий предметной области и связей между ними; описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
В процессе разработки ER-диаграммы определяются:
- типы сущностей;
- типы связей;
- атрибуты;
- домены атрибутов;
- потенциальные ключи;
- первичные ключи.
Сущность – любой конкретный или абстрактный объект в рассматриваемой предметной области. Сущности – это базовые типы информации, которые хранятся в БД. К сущностям могут относиться: студенты, клиенты, подразделения и т.д. Экземпляр сущности и тип сущности – это разные понятия. Понятие тип сущности относится к набору однородных личностей, предметов или событий, выступающих как целое (например, студент, клиент и т.д.). Экземпляр сущности относится, например, к конкретной личности в наборе. Типом сущности может быть студент, а экземпляром – Петров, Сидоров и т.д. Можно выделить следующие типы сущностей: сильные и слабые.
|
|
|
В таблице ниже указываются все существующие сущности базы данных, их описания, псевдонимы и типы.
Таблица 1 – Сведения о типах сущностей
| Имя сущности | Описание | Псевдоним | Тип |
| Шатры | Перечень тентовых конструкций, имеющихся у организации | tent | Сильный |
| Тип шатра | Тип тентовой конструкции | tent_type | Слабый |
| … | … | … | … |
То число сущностей, которое может быть ассоциировано через набор связей с другой сущностью, называют степенью связи (кардинальностью).
Кардинальность:
1. Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
2. Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи.
|
|
|
3. Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Сведения об имеющихся типах связей для разрабатываемой базы данных представляются в таблице ниже.
Таблица 2 – Сведения о типах связей
| Тип сущности | Тип связи | Тип сущности | Кардинальность |
| Шатры | Характеризуются | Тип шатра | М:1 |
| Шатры | Состоят | Детали шатра | 1:M |
| … | … | … | … |
Связи между сущностями в базе данных приведены на рисунке ниже.
Рисунок 1 – ER-диаграмма базы данных
Логическое проектирование
Логическое проектирование базы данных представляет собой процесс конструирования модели информационной структуры организации, выполняемый в соответствии с выбранной схемой организации информации (например, реляционной). Однако создаваемая логическая модель не зависит от особенностей конкретной СУБД и физических условий реализации.
|
|
|
Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Т. е., на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой – реляционная, сетевая, иерархическая или объектно-ориентированная. Однако на этом этапе игнорируются все остальные характеристики выбранной СУБД.
Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. В реляционной БД атрибуты хранятся в полях таблиц.
Домен атрибута – это набор значений, которые могут быть присвоены атрибуту. Атрибуты сущности содержат значения, описывающие каждую сущность. Значения атрибутов представляют основную часть сведений, сохраняемых в базе данных.
Данные об атрибутах и доменах атрибутов представлены в таблице 3.
Таблица 3 – Атрибуты и домены атрибутов
| Сущность | Атрибут сущности | Домен атрибута | Ограничение целостности | ||
| Шатры | Id шатра | Счетчик | Обязательное поле | ||
| Наименование шатра | Текстовый | - | |||
| Id типа шатра | Числовой | Ссылочная целостность | |||
| Размер шатра | Текстовый | - | |||
| Тип шатра
| Id типа шатра | Счетчик | Обязательное поле | ||
| Тип шатра | Текстовый | - | |||
| … | … | … | … |
На рисунке 2 представлена логическая схема базы данных. 
Рисунок 2 – Логическая схема базы данных
Физическое проектирование
Физическое проектирование базы данных – это процесс создания описания конкретной реализации базы данных, размещаемой во вторичной памяти. На этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.
Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.
Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. В случае реляционной модели данных под этим подразумевается следующее:
• создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
• определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;
• разработка средств защиты создаваемой системы.
Целью физического проектирования является создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных. Схема физического проектирования БД представлена на рисунке 3.
Рисунок 3 – Схема физического проектирования базы данных
Дата добавления: 2020-11-15; просмотров: 298; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!