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

• Перевод

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


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

Какой функционал требуется от базы данных

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

Фото: binaryape

Отстранитесь от базы данных. Попытайтесь подумать, что будет требоваться от сайта? Например, если требуется сделать сайт, объединяющий людей, вы, возможно, сразу начнете думать о данных, которые будут хранить пользователи. Забудьте, отложите это на потом. Лучше запишите, что пользователи и информация о них должна храниться в базе данных. А что еще? Что пользователи будут делать на вашем сайте? Будут ли они публиковать записи, загружать файлы, фотографии, писать друг другу сообщения? Следовательно, база данных должна хранить всю эту информацию: записи, файлы, фотографии, сообщения и т. д.
Как будут взаимодействовать пользователи с вашим сайтом? Будет ли у них необходимость в поиске, например, их любимых рецептов, иметь доступ к записям, доступным конкретному сообществу, искать продукты или смотреть список недавно просмотренных и купленных продуктов? В базе данных должна быть предусмотрена возможность хранить рецепты, «закрытые» записи, доступные определенному кругу пользователей, информацию о продуктах, а также возможность связи определенного продукта и пользователя.

Определение необходимых таблиц и полей

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

Используйте инструмент моделирования данных

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

Есть также более известный, качественный, на мой взгляд, инструмент - Microsoft Visio (только под Windows, цена $249.99). Но не пугайтесь, есть более дешевые альтернативы, многие из которых являются open-source проектами, в том числе два, упомянутых выше.
Ознакомьтесь с общими графическими обозначениями и стандартными визуальными элементами, необходимым для создания модели базы данных, и начните предварительное планирование с помощью блок-схем и диаграмм. Это позволит избежать логических ошибок, прежде чем будет создана уже какая-нибудь конкретная база данных.

Группировка и разделение данных

Что касается полей, также важно знать, когда группировать определенную часть данных, а когда нет. Хороший способ определить, какая информация должна быть в одном поле или наоборот, подумать, будет ли необходимость изменять какую-либо её часть? Например, нужно ли хранить адрес, разбив его на составляющие: 1) улица, 2) город, 3) штат, 4) почтовый код, 5) страна?
Это неотъемлемая часть функционала сайта (возможно, пользователи или администраторы захотят искать других пользователей по адресу или штату), или просто увеличение места, занимаемого базой данных на диске? Если это не столь важно, зачем тогда нагружать базу данных на изменение 5 полей, когда можно обновить всего лишь одно строковое поле. Более удобным может быть вариант получения этих данных из HTML-формы, где поля разделены, а уже перед добавлением адреса в базу данных объединять значения из соответствующих полей в одну строку.
Это только один пример, но всегда имейте представление о наиболее эффективные способы организации полей таблицы, когда объединять их, когда содержать отдельно, ради поддержания функциональности сайта.

Нормализация базы данных

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

Государственное бюджетное профессиональное

образовательное учреждение

«Колледж автоматизации

и информац ионных технологий № 20»

РАБОЧАЯ ПРОГРАММА

учебной дисциплины_ ОП.07 Основы проектирования баз данных

код специальности/специальность 230401 ИНФОРМАЦИОННЫЕ СИСТЕМЫ (по отраслям)

уровень подготовки: __базовый ________

Москва

2015

ОДОБРЕНО

на заседании ПЦК «Библиотековедение», «ИС (по отраслям», «ОТЗИ»

Протокол № _от « » ______ 2015 г.

Председатель

_____________________________/Е.Е. Швец/

Программа учебной дисциплины разработана в соответствии с требованиями ФГОС по специальности 230401 Информационные системы и учебным планом

УТВЕРЖДАЮ

Руководитель учебного структурного подразделения «БТМ»

_____________________________/Т.И. Стеняева/

СОГЛАСОВАНО

Зав. учебно-методическим отделением

_____________________________/С.Е. Коваленко/

«_____» ________________________20__ г.

Разработчик (автор): ____ Федоткина М.В., преподаватель _______ _________________________________________________

Ф.И.О., должность, квалификационная категория

Рецензент:

Внешний: ______________________________________________

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

СОДЕРЖАНИЕ

стр.

1. ПАСПОРТ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ

1. СТРУКТУРА и содержание УЧЕБНОЙ ДИСЦИПЛИНЫ

1. условия реализации учебной дисциплины

1. Контроль и оценка результатов Освоения учебной дисциплины

1. паспорт Рабочей ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ

« ОП.07 Основы проектирования баз данных»

1. Область применения рабочей программы

Рабочая программа учебной дисциплины является частью основной профессиональной образовательной программы в соответствии с ФГОС по специальности СПО 230401 «Информационные системы (по отраслям) (базовый уровень) укрупненной группы специальностей 230000 Информатика и вычислительная техника.

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

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

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

1.2. Место учебной дисциплины в структуре основной профессиональной образовательной программы:

Учебная дисциплина относится к циклу профессиональных дисциплин к блоку общепрофессиональных дисциплин.

1.3. Цели и задачи учебной дисциплины - требования к результатам освоения учебной дисциплины:

Изучение дисциплины «Основы проектирования баз данных» направлено на формирование общих компетенций (ОК 1-10) и ПК 1.1, ПК 1.2, ПК 1.3, ПК 1.7,ПК 1.9. согласно ФГОС по специальности 230401 Информационные системы (по отраслям):
ОК 1. Понимать сущность и социальную значимость своей будущей профессии, проявлять к ней устойчивый интерес.

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

ОК 3. Принимать решения в стандартных и нестандартных ситуациях и нести за них ответственность.

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

ОК 5. Использовать информационно-коммуникационные технологии в профессиональной деятельности.

ОК 6. Работать в коллективе и команде, эффективно общаться с коллегами, руководством, потребителями.

ОК 7. Брать на себя ответственность за работу членов команды (подчиненных), результат выполнения заданий.

ОК 8. Самостоятельно определять задачи профессионального и личностного развития, заниматься самообразованием, осознанно планировать повышение квалификации.

ОК 9. Ориентироваться в условиях частой смены технологий в профессиональной деятельности.

ОК 10. Исполнять воинскую обязанность, в том числе с применением полученных профессиональных знаний (для юношей).

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

ПК 1.2. Взаимодействовать со специалистами смежного профиля при разработке методов, средств и технологий применения объектов профессиональной деятельности

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

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

В результате освоения дисциплины обучающийся должен

уметь :

Проектировать реляционную базу данных;

Использовать язык запросов для программного извлечения сведений из баз данных;

знать :

Основы теории баз данных;

Модели данных; особенности реляционной модели и проектирование баз данных, изобразительные средства, используемые в ER-моделировании;

Основы реляционной алгебры; принципы проектирования баз данных,

Обеспечение непротиворечивости и целостности данных;

Средства проектирования структур баз данных; язык запросов SQL
1.4. Рекомендуемое количество часов на освоение примерной программы учебной дисциплины:

максимальной учебной нагрузки обучающегося 168 часов, в том числе:

обязательной аудиторной учебной нагрузки обучающегося 112 часа,

самостоятельной работы обучающегося 56 часов.

2. СТРУКТУРА И ПРИМЕРНОЕ СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ

2.1. Объем учебной дисциплины и виды учебной работы

Вид учебной работы

Объем часов

168

Обязательная аудиторная учебная нагрузка (всего)

112

в том числе:

лабораторные работы

48

практические занятия

10

контрольные работы

-

курсовая работа (проект) (если предусмотрено)

-

Самостоятельная работа обучающегося (всего)

56

в том числе:

самостоятельная работа над курсовой работой (проектом) не предусмотрено

-

Подготовка доклада на тему:

- «Информационные технологии будущего»;

- « Для каких объектов Acces можно создавать отчёты»;

- «Смысл новых перспективных направлений развития СУБД»;

Подготовка презентации на тему:

- «Способы задания таблиц в Access »;

- «Процесс создания запрос – выборка»;

Подготовка сообщения на тему:

- «Объекты программного средства (ПС) Access их назначение»;

- «Объект – Форма»;

- « Направление СУБД – Postgres »;

Реферат на тему:

- «Способы удаления атрибута в таблице»;

- «Опишите процесс установления связи между двумя таблицами в Acces »;

Выполнение индивидуального проекта тему :

- «Расписание занятий»;

9

Итоговая аттестация в форме экзамена

2.2. Тематический план и содержание учебной дисциплины оп.07 ОСНОВЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

Наименование

разделов и тем

Содержание учебного материала, лабораторные и практические работы, самостоятельная работа

обучающихся, курсовая работ (проект)

Объем часов

Уровень

освоения

1

2

3

4

Введение

Введение в теорию баз данных

Лабораторные работы не предусмотрено

Практические занятия не предусмотрено

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся не предусмотрено

Подготовить реферат на тему: «Связь БД с другими дисциплинами».

Раздел 1.

Базы данных. Основные понятия

12

Тема 1.1. Основные понятия и типы моделей данных

Содержание учебного материала

6

Дать понятия объекта, сущности, параметра, атрибута, модели данных. Рассмотреть состав информационной модели данных.

3

СУБД и ее место в системе программного обеспечения ЭВМ. Функции СУБД . Уровни представления данных.

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

Лабораторные работы не предусмотрено

-

-

Практические занятия не предусмотрено

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся

1. Подготовка доклада на тему «Информационные технологии будущего»

3

Тема 1.2. Архитектура СУБД

Содержание учебного материала

2

Архитектуры баз данных (двух- и трёх-звенная структуры, клиент – сервер, файл - сервер).

Лабораторные работы не предусмотрено

-

Практические занятия не предусмотрено

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся

2.Сообщение на тему: «Объекты программного средства (ПС) Access их назначение»

1

Раздел 2. Проектирование базы данных

114

Тема 2.1. Концепция проектирования

Содержание учебного материала

2

Типы моделей данных корпоративного хранилища данных. Обеспечение непротиворечивости и целостности данных. Основные этапы разработки БД.

3

Лабораторные работы не предусмотрено

Практические занятия

Анализ предметной области.

Проектирование концептуальной модели БД.

Формализация реляционной модели.

6

Контрольные работы не предусмотрено

-

Самостоятельная работа обучающихся

3.Презентация на тему: «Способы задания таблиц в Access »

4

Тема 2.2. Модели данных. Реляционная модель данных.

Содержание учебного материала

6

Типы взаимосвязей в модели: «один – к- одному», «один- ко -многим» и «многие- ко многим». Реляционный подход к построению модели данных. Особенности реляционной модели и их влияние проектирование баз данных.

3

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

Основные операции реляционной алгебры

Лабораторные работы не предусмотрено

-

Практические занятия не предусмотрено

Магистрально-модульный принцип построения компьютера. Внутренняя архитектура компьютера; процессор, память. Периферийные устройства: клавиатура, монитор, дисковод, мышь, принтер, сканер, модем, джойстик; мультимедийные компоненты. Программный принцип управления компьютером. Операционная система: назначение, состав, загрузка. Виды программ для компьютеров. Понятие файла, каталога (папки) и правила задания их имен. Шаблон имени файла. Путь к файлу. Ввод команд. Инсталляция программ. Работа с каталогами и файлами.

-

Контрольные работы не предусмотрено

-

Самостоятельная работа обучающихся

4. Реферат на тему: «Способы удаления атрибута в таблице».

3

Тема 2.3. Проектирование базы данных

Содержание учебного материала

16

Понятие, назначение и принцип построения .

Индексирование: понятие индекса, типы индексных файлов. Создание, активация и удаление индекса. Переиндексирование. Сортировка, поиск и фильтрация данных.

Взаимосвязи между таблицами: установление и удаление. Типы ключей. Способы объединения таблиц.

Создание программных файлов. Модульность программ. Область действия переменных.

Типы меню. Работа с меню: создание, модификация, активация и удаление.

Работа с окнами: открытие и закрытие окна, получение справки.

Создание экранной формы: свойства, события и методы. Элементы управления: свойства, события и методы.

Формирование и вывод отчетов

Лабораторные работы

1. Создание базы данных в программе MS Access. Создание таблиц.

2. Создание таблиц.

3. Импорт и экспорт данных

4. Импорт и экспорт данных

5. Создание запросов

6. Создание запросов

7. Создание запросов

8. Создание форм

9. Создание форм

10. Создание форм

11. Создание отчетов

12. Создание отчетов

13. Создание отчетов

14.

15. Создание главной кнопочной формы

30

Практические занятия

Проектирование структуры базы данных.

Нормализация таблиц.

4

Контрольные работы не предусмотрено

-

Самостоятельная работа обучающихся

Выполнение индивидуального проекта тему:

- «Организация работы студенческой библиотеки»;

- «Организация работы университетской типографии»;

- «Организация познавательных экскурсий для школьников»;

- «Организация контроля за успеваемостью ученика»;

- «Расписание занятий»;

25

Тема 2.4.

Физическая организация данных

Содержание учебного материала

6

Механизмы среды хранения и архитектура СУБД

Структура хранимых данных

Виды адресации хранимых записей. Организация связей между хранимыми записями

Лабораторные работы не предусмотрено

-

Практические занятия не предусмотрено

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся

Доклад на тему: « Для каких обьестов Acces можно создавать отчёты»

3

Тема 2.5.

Управление реляционной базой данных

Содержание учебного материала

4

Управление данными – основа администрирования БД. Основная концепция управления данными.

Организация управления данными. Администрирование БД.

Лабораторные работы не предусмотрено

-

Практические занятия не предусмотрено

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся

Сообщение на тему: «Объект – Форма»

2

Раздел 3.

Языки баз данных

14

Тема 3.1

Язык SQL

Содержание учебного материала

6

Язык запросов SQL

Команды языка запросов SQL на изменение: создание файла базы данных, создание таблицы, добавление, редактирование и удаление записей.

Запрос на выборку данных: выборка данных из одной таблицы или нескольких таблиц, с сортировкой и группировкой данных, с условием отбора записей (фильтрацией).

Лабораторные работы

16. Создание SQL-запросов

17. Создание SQL-запросов

18. SQL запросы

19. SQL запросы

8

Практические занятия не предусмотрено

-

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся

Презентация на тему: «Процесс создания запрос – выборка»

7

Раздел 4. Использование базы данных

30

Тема 4.1.

Обеспечение функционирования баз данных

Содержание учебного материала

4

Организация системы управления БД

Обобщенная технология работы с БД

Лабораторные работы не предусмотрено

-

Практические занятия не предусмотрено

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся

Реферат на тему: «Опишите процесс установления связи между двумя таблицами в Acces »

2

Тема 4.2. Новые технологии БД

Содержание учебного материала

6

Современные информационные технологии – мониторинг информационных ресурсов;

Применение case – технологий для проектирования БД и приложений;

Современные информационные технологии – распространение данных с широким применением Web – технологий. ГИС для визуализации данных и создания электронных справочных пособий.

Лабораторные работы не предусмотрено

-

Практические занятия не предусмотрено

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся

Доклад на тему: «Смысл новых перспективных направлений развития СУБД»

3

Тема 4.3.

Современные СУБД

Содержание учебного материала

4

Много платформенные СУБД.СУБД, ориентированные на конкретные платформы.

СУБД семейства XBase, Dbase.Перспективы развития БД и СУБД

Лабораторные работы не предусмотрено

-

Практические занятия не предусмотрено

Контрольные работы не предусмотрено

Самостоятельная работа обучающихся

Сообщение на тему: « Направление СУБД – Postgres »

2

Итого:

168

3. условия реализации УЧЕБНОЙ дисциплины

3.1. Требования к минимальному материально-техническому обеспечению

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

Оборудование учебного кабинета:

Перечень основного оборудования:

сетевой компьютерный класс с выходом в Интернет;

посадочные места по количеству обучающихся;

шкафы для методической литературы;

информационные стенды.

Технические средства обучения:

интерактивная доска- Interwrite ;

проектор-Epson ;

компьютерное рабочее место для преподавателя;

Принтер-HP Deskjet 1280 ;

Сканер-Epson perfection v200 PHOTO.

Описание оборудования на рабочем месте:

Процессортипа Intel® Core™ i5-2400

Процессор с тактовой частотой 3.10Ghz ;

ОЗУ 4,0 GB ;

HDD 2Tb ;

Акустическая система –Genius ;

операционная система - Windows 7x 32 ;

антивируснаяпрограмма -Microsoft security Essentials ;

Программа архиватор-Winrar ;

офисное ПО: текстовый процессор, табличный процессор, программа для создания мультимедийных презентаций-Microsoft office 2007;

система управления базами данных-Microsoft office 2007;

интегрированная среда разработки программного обеспечения-Microsoft office 2007;

система визуального проектирования-Microsoft office 2007.

3.2. Информационное обеспечение обучения

Основные источники:

Матросов В.Л.,Жданов С.А.,Соболева М.Л. Информационные системы в структурно логических схемах.-М.:МПГУ, 2014.-105с.

Фуфаев Э.В., Фуфаев Д.Э. Базы данных-М.: «Академия»,2011-320с.

Дополнительные источники:

Матросов В.Л.,Жданов С.А.,Иванова Н.Ю.,Маняхина В.Г., Костин А.Н. Информатика-М.: «Академия»,2012-336с.

4. Контроль и оценка результатов освоения УЧЕБНОЙ Дисциплины

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

Результаты обучения

(освоенные умения, усвоенные знания)

Формы и методы контроля и оценки результатов обучения

1

2

Умения:

проектировать реляционную базу данных;

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

Комбинированный: лабораторный практикум, рефераты (доклады), отчеты по лабораторному практикуму.

Знания:

основы теории баз данных;

Групповой: рефераты (доклады)

модели данных;

особенности реляционной модели и их влияние проектирование баз данных,

Групповой: рефераты (доклады).

изобразительные средства, используемые в ER-моделировании;

Групповой: рефераты (доклады).

основы реляционной алгебры;

Групповой: рефераты (доклады).

принципы проектирования баз данных,

Групповой: рефераты (доклады).

обеспечение непротиворечивости и целостности данных;

Групповой: рефераты (доклады

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

Групповой: рефераты (доклады

язык запросов SQL

Групповой: рефераты (доклады).

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

Разработанная функциональная модель системы отвечает на вопросы «Что должна делать система?» и «За счет каких действий может быть достигнут требуемый результат?». Эта модель также позволяет концептуально определить наборы данных, используемых в системе.

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

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

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

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

Атрибут (столбец, поле) – свойство сущности или связи.

Большинство современных моделирования данных, как правило, поддерживает несколько графических нотаций построения информационных моделей. В частности система ERwin фирмы Computer Associates поддерживает две нотации: и (англ. Information Engineering – информационное проектирование). Данные нотации являются взаимно-однозначными, т.е. переход от одной нотации к другой и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели.

При использовании любого вначале строится логическая схема БД в виде диаграммы с указанием сущностей и связей между ними. Логической схемой называется универсальное описание структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. На основании полученной логической схемы переходят к физической схеме данных. Физическая схема представляет собой диаграмму, содержащую всю необходимую информацию для генерации БД для конкретной СУБД или даже конкретной версии СУБД. Если в логической схеме не имеет значения, какие идентификаторы носят таблицы и атрибуты, тип данных атрибутов и т. д., то в физической схеме должно быть полное описание БД в соответствии с принятым в ней синтаксисом, с указанием типов атрибутов, хранимых процедур и т.д. По одной и той же логической схеме можно создать несколько физических. Например, ERwin v9.2 позволяет на основании логической схемы сформировать физические более, чем для 10 промышленных СУБД (ORACLE, MySQL, DB2, MS SQL Server и др.) и их различный версий. На основании физической схемы можно сгенерировать либо саму БД или DDL-скрипт 1 , который, в свою очередь, может быть использован для генерации БД.

Перечисленный выше порядок действий называется прямое проектирование БД (Forward Engineering DB) . позволяют выполнять также обратное проектирование БД (Reverse Engineering DB) , т.е. на основании системного каталога БД или DDL-скрипта построить физическую и, далее, логическую схему данных.

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

Развитые CASE-средства обладают также встроенной подсистемой поиска и исправления ошибок в схеме . Особенно полезна эта функция при проектировании больших БД, содержащих десятки или сотни таблиц, а также при обратном проектировании.

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

Далее рассматривается процедура прямого проектирования с использованием методологии IDEF1X. Методология IDEF1 была разработана Т. Рэмеем. В настоящее время на основе IDEF1 создана ее новая версия – методология IDEF1X, которая в 1981 г. принята ICAM в качестве федерального стандарта США.

1 Data Definition Language – язык определения данных, подмножество языка SQL.

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

Содержание проектирования баз данных и этапность

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

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

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

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

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

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

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

Таким образом, основные этапы проектирования в детализированном виде представлены этапами:

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

Ключевые из них ниже будут рассмотрены подробнее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:

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

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

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

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

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

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

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

Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:

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

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

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

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

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

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

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

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

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

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

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

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

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

Существуют следующие основные модели данных:

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

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

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

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

Таблица в реляционной базе данных рассматривается как непосредственное «хранилище» данных. Традиционно в реляционных схемах таблицу называют отношением. Строку таблицы называют кортежем, а столбец - атрибутом. При этом атрибуты имеют уникальные (в пределах отношения) имена. Количество кортежей называют кардинальным числом, а количество атрибутов - степенью. Для отношения предусматривается идентификатор, то есть один из нескольких атрибутов, значения которых в одно и то же время не бывают одинаковыми - идентификатор называют первичным ключом.

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

Отношение содержит две части - заголовок и собственную содержательную часть. Заголовок содержит конечное множество атрибутов, а содержательная часть (тело отношения) - множество имени атрибута и его значения.

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

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

• 1. Выборка отношения;
• 2. Проекция отношения;
• 3. Объединение отношений;
• 4. Пересечение отношений;
• 5. Вычитание отношений;
• 6. Произведение отношений;
• 7. Соединение отношений;
• 8. Деление отношений;

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

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

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

На логическом уровне можно установить связи:

• 1. один-к-одному;
• 2. один-ко-многим;
• 3. многие-ко-многим;
• 4. многие-к-одному;

Этапы физической реализации проектируемой базы данных

Реализация - это этап превращения концептуальной модели в функционирующую базу данных. Реализация включает этапы:

• 1. Выбор и приобретение СУБД.
• 2. Преобразование концептуальной модели в физическую модель.
• 3. Построение словаря.
• 4. Заполнение базы данных.
• 5. Создание прикладных программ.
• 6. Обучение пользователей.