Заключительная фаза анализа предметной области состоит в проектировании ее информационной структуры или концептуальной модели.
Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области (ПО) и выявляемых в результате анализа данных.
Концептуальная модель применяется для структурирования предметной Области с учетом информационных интересов пользователей системы. Она Дает возможность систематизировать информационное содержание предметной области, позволяет как бы "подняться вверх" над ПО и увидеть ее отдельные элементы. При этом, уровень детализации зависит от выбранной модели.
Концептуальная модель является представлением точки зрения пользователя на предметную область и не зависит ни от программного обеспечения СУБД, ни от технических решений.
Концептуальная модель должна быть стабильной. Могут меняться прикладные программы, обрабатывающие данные, может меняться организация их физического хранения, концептуальная модель остается неизменной или увеличивается с целью включения дополнительных данных.
Одной из распространенных моделей концептуальной схемы является модель «сущность - связь». Основными конструкциями данной модели являются сущности и связи.
Под сущностью понимают основное содержание объекта ПО, о котором собирают информацию. В качестве сущности могут выступать место, вещь, личность, явление.
Экземпляр сущности - конкретный объект.
Например:
сущность (объект) - институт экземпляр сущности -СГУТиКД.
Сущность принято определять атрибутами - поименованными характеристиками. Например:
сущность студент
атрибуты: ФИО, Группа,
Пример. Спроектировать БД "Сессия". База данных должна выдавать оперативную информацию об успеваемости студентов на факультетах в семестре. Результатами сессии считать только экзамены.
По сути дела, в БД исходя из формулировки задания, можно выделить лишь одно приложение. Речь идет об успеваемости студентов разных факультетов по тем или иным дисциплинам. Более конкретно речь идет о выдаче справок по результатам сессии каждого студента, учебной группы, курса. (Факультета, а также об автоматизированном составлении ведомости.)
Выберем следующие сущности:
УНИВЕРСИТЕТ, ИНСТИТУТ, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА.
В данном примере можно выделить сущность ЭКЗАМЕН или ВЕДОМОСТЬ, но можно не выделять, а сформировать ведомость из имеющихся данных посредствам связей.
Зададим каждую сущность набором атрибутов, например:
УНИВЕРСИТЕТ (название, подчиненность, адрес, телефон, ФИО ректора).
ИНСТИТУТ (название, код специальности, группы, декан).
СТУДЕНТ (ФИО, группа, курс, номер семестра).
ПРЕПОДАВАТЕЛЬ (ФИО, должность, звание, институт, читаемые дисциплины).
ДИСЦИПЛИНА (название, число часов, виды занятий, номер семестра, итоговая аттестация)
В каждом наборе атрибутов, характеризующих сущность, необходимо выбрать ключевые атрибуты, т.е. атрибуты, делающие сущность уникальной. При задании атрибутов ключевые атрибуты подчеркивались. Определим связи между сущностями.
| Название связи | Сущность 1 | Сущность 2 | Сущность 3 |
| учится | студент | институт | |
| изучает | студент | дисциплина | |
| имеет | университет | институт | |
| работает | преподаватель | институт | |
| преподает | преподаватель | дисциплина | |
| экзамен | студент | дисциплина | преподаватель |
После выбора сущностей, задания атрибутов и анализа связей можно перейти к проектированию информационной (концептуальной) схемы БД.
Концептуальная схема БД "Успеваемость» представлена на рис. 2.5
(атрибуты сущностей на диаграмме не показаны).
Рассмотрим некоторые ограничения в рассматриваемом примере:
1. Значение атрибута "курс" (сущность - СТУДЕНТ) лежит в интервале 1-6.
4. Значение атрибута "семестр" (сущность - СТУДЕНТ, ДИСЦИПЛИНА) в интервале 1-12.
5. Значение атрибута "число часов" (сущность - ДИСЦИПЛИНА) лежит в интервале 1-300.
6. Одному студенту может быть приписана только одна группа.
7. Один студент может учиться только на одном факультете.
8. Один студент в семестре сдает от 3 до 5 дисциплин.
9. Один студент изучает в семестре от 6 до 12 дисциплин.
10. Одному преподавателю приписывается только один институт.
11. Один студент может пересдавать одну дисциплину не более трех раз.
12. Ключи: название института, название университета, ФИО и группа студента, ФИО и преподавателя, название дисциплины.
При проектировании БД могут быть альтернативные схемы отношений. При выборе неоптимальных схем отношений у БД могут появиться нежелательные свойства, такие как избыточность, аномалии обновления, аномалии включения, аномалии удаления и др.
Для уменьшения нежелательных характеристик БД к схемам отношений применяют процедуры нормализации. Рассмотрим понятие функциональной зависимости. Пусть R (A1, A2,...,Ai,...,An) - схема отношения R. Обозначим через Dom (Aj) множество возможных состояний атрибута Aj. Будем говорить, что атрибуты Ai и AJ отношения К связаны функциональной зависимостью, т.е. f: Dom (Ai) -> Dom (Aj), которую будем понимать как множество упорядоченных пар
{ <а, в> / а€ Dom (Ai), b€ Dom (Aj) },
где f - имя функциональной зависимости, символ -> разделяет правую и левую части выражения.
При этом в каждый момент элементу а€ Dom (Ai) соответствует не более
одного элемента b€ Dom (Aj).
Функциональная связь доменов инвариантна по отношению к схеме конкретного отношения. Понятие функциональной зависимости позволяет определить ключ отношения. Пример 1.
Выявим функциональные зависимости в отношении БД "Учеба". R учеба (факультет, группа, дисциплина, вид занятий, преподаватель, квалификация преподавателя)
f: (дисциплина, вид занятий) -> квалификация преподавателя преподаватель -> квалификация преподавателя
группа -> факультет преподаватель -> факультет
Фиксация функциональных зависимостей в схеме отношения ограничивает число возможных состояний схемы.
Логическое проектирование
Логическое проектирование представляет собой необходимый этап при создании БД. Основной задачей логического проектирования является разработка логической схемы, ориентированной на выбранную систему управления базами данных (СУБД).
Процесс логического проектирования состоит из следующих этапов:
1. Выбор конкретной СУБД.
2. Отображение концептуальной схемы на логическую схему.
3. Выбор ключей.
4. Описание языка запросов.
Одним из основных критериев выбора СУБД является оценка того. насколько эффективно внутренняя модель данных, поддерживаемая системой, способна описать концептуальную схему. Системы управления базами данных, ориентированные на персональные компьютеры, как правило, поддерживают реляционную или сетевую модель данных. Подавляющее большинство современных СУБД - реляционные. Если выбрана реляционная система, то концептуальную схему БД предстоит отображать на реляционную.
По сути дела выбранная модель данных (реляционная, сетевая или иерархическая) представляет средства для описания структуры данных. Процедуры выполняются на языке описания данных (ЯОД), который входит в ядро СУБД.
Второй составной частью СУБД является язык манипулирования данными (ЯМД), который используется при работе различных приложений с БД. Как правило, ЯМД встраивается в язык программирования. Языки манипулирования данными могут обладать разными возможностями: ЯМД низкого уровня обычно бывают процедурные, высокого уровня - декларативные. Использование процедурных языков требует определенной подготовки, декларативные языки более пригодны для непрофессионального пользователя. Поэтому выбор СУБД, имеющей определенный ЯМД, весьма существен для неподготовленного пользователя. Кроме ядра в СУБД входят сервисные программы и средства для решения прикладных задач. СУБД, ориентированные на персональные компьютеры, отличаются более простой структурой, чем СУБД для мощных ЭВМ.
При выборе СУБД, реализующей конкретную БД, выделяют два подхода к ее оценке. Первый подход связан с взглядом пользователя на конечную систему, а второй- сугубо технический, связан с производительностью системы. С учетом этой системы рассмотрим семь групп параметров для характеристики и последующего выбора СУБД. Данные параметры, не претендуя на исчерпывающую полноту, тем не менее, дают достаточно полную картину о возможностях СУБД.
1. Общие характеристики:
тип ПЭВМ; максимальное число записей в файле; максимальный объем файла; максимальное число копий в записи; максимальное число символов на запись; максимальное число индексов на файл; максимальное число таблиц в операции соединения; максимальное число файлов, доступных для одной команды; максимальное число одновременно открытых файлов; максимальное число файлов в БД; максимальное число записей в БД; максимальное число переменных; максимальное число символов в одном поле; импорт-экспорт данных; прямой доступ; поля переменной длины; многозначные поля; тип внутренней модели данных; фирма-изготовитель; версия; название русифицированной версии.
2. Управление файлами и поиск:
тип связи; модификация нескольких файлов; двунаправленное соединение таблиц; ЯМД; тип поиска.
3. Средства поддержки приложений:
каталог данных; генератор приложений; процедурный язык; подпрограммы; макросы; отладчик; система поддержки исполнения; шифровка программ и данных; разграничение доступа; графика; графика цветная; текстовый редактор; экранный художник; статистика.
4. Ввод и поддержание целостности:
управление с помощью команд; управление с помощью меню; проверка целостности по таблице; проверка уникальности ключа; проверка по дате; независимость данных.
5.Отчеты:
отчеты по нескольким файлам; сохранение форматов отчета; выдача отчета на экран; выдача отчета на магнитный носитель; вычисляемые поля; группы; переопределение формата даты; формат "почтовой карточки"; заголовки отчетов; генератор отчетов; окончание отчета; итоговые поля; максимальная ширина отчета; отчет в матричной форме.
6.Операционная среда:
тип операционной системы; объем требуемой оперативной памяти; необходимость использования постоянной памяти; объем требуемой постоянной памяти; язык системы.
7.Дополнительные сведения:
наличие сетевого варианта; стоимость; примечание; источники.
При отображении концептуальной схемы на реляционную модель, каждый прямоугольник схемы отображается в таблицу. Отобразим, например сущность ПРЕПОДАВАТЕЛЬ описываемую атрибутами ФИО, должность, звание, кафедра, стаж, в виде таблицы.
ПРЕПОДАВАТЕЛЬ
| ФИО | Должность | Звание | Институт | Дисциплина |
Определим структуру каждой таблицы, то есть типы и размеры полей.
| Признак ключа | Поле | Тип поля | Размер поля |
| ключ | ФИО | текстовый | |
| Должность | текстовый | ||
| Звание | текстовый | ||
| Ключ | Институт | текстовый | |
| Дисциплина | текстовое |
Выводы
Концептуальная модель представляет объекты предметной области и их взаимосвязи, без указания способа их физического хранения.
При проектировании концептуальной модели все усилия должны быть направлены на структуризацию данных и выявление взаимосвязи между ними.
Концептуальная модель транспонируется затем в модель данных, совместимую с выбранной СУБД, называется логической моделью.
Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения.
Логическая модель может быть реляционной, иерархической, сетевой. Она отображается в физическую память, такую как диск, лента.
Физическая модель, определяет размещение данных, методы доступа и технику индексирования и называется внутренней моделью системы.
В современных СУБД выполнение задач физического проектирования осуществляется автоматически.
РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
Ее построение основано на аппарате математической теории отношений. Результатом разработок в данной области является построение теоретико-множественной модели базы данных, получившей название реляционной модели, и выделение набора процедур манипулирования хранимыми в ней данными. Подобные наборы положены в основу целого спектра возможных языков.
Реляционная модель данных характеризуется следующими компонентами:
• информационной конструкцией - отношением с двухуровневой структурой,
• допустимыми операциями: проекцией, выборкой, соединением и некоторыми другими,
• ограничениями - функциональными зависимостями между атрибутами отношения.
Каждому классу объектов Р материального мира ставится в соответствие некоторое множество атрибутов, например А 1, А2,...,Ап. Отдельный объект класса Р описывается строкой величин (а1, а2,..., an), где ai - значение атрибута Ai.
Строка (а1, а2,..., an) называется кортежем. Всему классу объектов соответствует множество кортежей, называемое отношением. Обозначим отношение, описывающее класс объектов Р, также через Р.
Выражение Р(А1, А2,...,Ап) называется схемой отношения Р.
Для каждого компонента кортежа должна быть указана ее связь с соответствующим атрибутом. В реляционной модели данных для обеспечения этой связи порядок компонентов кортежа совпадает с порядком следования атрибутов в схеме отношения.
Каждое отношение представляет состояние класса объектов в некоторый момент времени. Следовательно, одной схеме отношения в разные моменты времени могут соответствовать разные отношения.
Множество значений отношения можно представить в виде таблицы, в которой соблюдаются следующие соответствия:
• название таблицы и перечень названий граф соответствуют схеме отношения,
• строке таблицы соответствует кортеж отношения,
• все строки таблицы (и соответственно все кортежи) различны,
• порядок строк и столбцов произвольный (в частности, реляционная модель данных не предполагает специальную сортировку строк).
Отношение реляционной БД может быть описано в терминах теории множеств. Рассмотрим множество доменов
D = { Dl, D2, D3,..., Dk } и создадим декартово произведение доменов
U=Dl-D2.D3.....Dk.
Каждый элемент U имеет вид (dl, d2, d3,...,dk),
где dl - элемент домена Dl, d2 - элемент D2 и т.д. В множестве U представлены всевозможные сочетания значений доменов, полученные по названному принципу.
Среди элементов из U содержатся такие, которые не соответствуют реально имеющимся сообщениям и не могут храниться в БД. Отношение R, включающее истинные сообщения, является подмножеством U. Атрибуты отношения R используют домены из D в качестве своих областей определения.
Реляционная база данных представляет собой множество отношений.
Схема реляционной БД содержит следующие компоненты
S(rel) = <A,R,Dom,Rel,V(s)>,
где А - множество имен атрибутов,
R - множество имен отношений, Dom - вхождение атрибутов в домены, Rel - вхождение атрибутов в отношения,
V(s) - множество ограничений (в том числе функциональных зависимостей).
Описание процессов обработки отношений может быть выполнено двумя способами:
• указанием перечня операций, выполнение которых приводит к требуемому результату (процедурный подход),
• описанием свойств, которым должно удовлетворять результирующее отношение (декларативный подход).
Приводимые далее операции над отношениями ориентированы на процедурное описание процессов обработки данных.
Множество отношений и операций над ними образует реляционную алгебру.
При рассмотрении операций над отношениями будем использовать как алгебраическую форму записи операций, так и запись на языке реляционных СУБД семейства dBASE. Далее будут рассмотрены аналогичные конструкции языка SQL.
Как правило, список операций содержит:
· проекцию,
· выборку,
· объединение,
· пересечение,
· вычитание,
· соединение
· деление.
Проекцией называется операция, которая переносит в результирующее отношение те столбцы исходного отношения, которые указаны в условии операции. Алгебраическая запись проекции имеет вид:
Т = R[X],
где R - исходное отношение,
Т - результирующее отношение,
Х - список атрибутов в структуре отношения Т (условие проекции).
Пример
|
| W1 | |||
| Магазин | Продукция | План | Факт |
| Динамо Динамо Спорттовары Спорттовары | Гидрокостюм Лыжи Лыжи Коньки | 1200 2000 | 1400 20001700 500 |
Если требуется отношение XI, содержащее сведения только о фактическом выпуске продукции, то оно получается в результате выполнения проекции
XI = Wl[Maгазин, Продукция, Факт] и имеет вид:
Столбцы результирующего отношения могут указываться в любом порядке:
Х2 = Wl[Пpoдyкция, Магазин, Факт].
В СУБД DBASE проекция реализуется двумя командами
