3 Источники данных для концептуального проектирования
Исходя из сказанного выше, концептуальное проектирование может рассматриваться как определение сущностей, атрибутов и связей. Для решения этой задачи необходимо найти источники сведений о бизнес – процессах моделируемой предметной области.
Основные источники:
- сведения, полученные от экспертов;
- документальные источники.
Работа с экспертами.
Необходимо собеседование с несколькими экспертами, так как один человек не может оценить потребности всей организации в данных.
Необходимо уметь задавать экспертам нужные вопросы, ответы на которые помогут, например, отличить сущности от атрибутов.
Терминология, используемая экспертами, может не подходить для целей моделирования данных. Часто возникает необходимость обобщения и уточнения терминов.
Эксперты должны участвовать в проверке построенной концептуальной модели данных, т.к. только они смогут проверить модель на соответствие реальным процессам предметной области.
Работа с документальными источниками.
В качестве документальных источников может использоваться различная справочная, учебная и методическая литература. Данные источники не отменяют работу с экспертами, но дополняют и уточняют сведения, полученные из других источников.
При осуществлении сбора данных необходимо помнить, что концептуальная модель отражает самое общее представление о процессах, происходящих в предметной области. Поэтому нет необходимости обнаруживать и документировать каждый атрибут каждой сущности, точно определять типы данных и т.п.
4 Построение концептуальной схемы
В настоящее время не существует единственного стандартного набора графических символов для построения концептуальной схемы.
Предлагается
использовать учебный вариант графической
нотации в виде следующего набора условных
обозначений (рисунок 1).
Рисунок 1- Условные обозначения
Рассмотрим пример концептуальной схемы для следующей предметной области: в базе данных хранится информация о сотрудниках, аспирантах и студентах некоторого учебного заведения, видах спорта (бег на 100м у мужчин, прыжки в длину у женщин и т.д.), категории вида спорта (лёгкая атлетика и т.д.) и соревнованиях, в которых участвуют сотрудники, аспиранты и студенты.
Рисунок 2 – Пример концептуальной схемы
На рисунке показаны не все атрибуты и связи. Данный рисунок демонстрирует способы использования графических символов.
5 Анализ концептуальной модели
Концептуальная модель данных должна пройти рецензирование всеми заинтересованными участниками разработки проекта.
Важно проверить возможность выполнения тех запросов, которые разные группы пользователей могут использовать на этапе эксплуатации базы данных.
Полезно определить, какие фрагменты концептуальной модели представляют интерес для каждой выделенной группы пользователей. В дальнейшем эта информации может быть использована для определения прав доступа к объектам базы данных и создания представлений.
Вернуться в содержание
Раздел «Логический уровень проектирования бд»
Лекция №6
Модели данных логического уровня. Введение
1 Исходные данные для проектирования
Минимальный набор исходных данных для проектирования модели данных логического уровня включает:
концептуальную модель данных;
тип СУБД (поддерживаемая модель данных);
2 Результаты проектирования
СУБД-ориентированная модель данных.
Подсхемы БД – представления разных групп пользователей.
Требования для физического проектирования.
3 Модели данных логического уровня
Модели данных логического уровня отличаются друг от друга по тем структурам данных, которые используются для хранения данных.
В настоящее время известны следующие модели данных:
- иерархическая;
- сетевая;
- реляционная;
- постреляционная или объектно-реляционная;
- объектная;
- на основе XML.
Каждая СУБД поддерживает определенную модель данных, поэтому модели данных логического уровня называют СУБД-ориентированными.
3.1 Иерархическая модель
Основной структурой данных в иерархической модели является дерево. Пример модели приведен на рисунке 1.
Рисунок 1 - Иерархическая модель данных
3.2 Сетевая модель
В сетевой модели основной структурой данных является граф, на который накладываются определенные ограничения.
Теоретически в сетевой модели любой элемент данных может быть связан с любым другим элементом. Практически допустимость тех или иных связей зависит от возможностей СУБД.
Принято различать простые и сложные сетевые структуры, двухуровневые, многоуровневые структуры и структуры с циклами. Некоторые варианты сетевых структур приведены на рисунке 2.
На рисунке 3 приведен пример конкретной сетевой модели, которая построена в предположении, что одни и те же виды работ могут выполняться
а) древовидные двухуровневые структуры (наборы CODASYL);
б) древовидные многоуровневые структуры;
в) простые сетевые структуры;
г) сложные сетевые структуры.
Рисунок 2 - Категории сетевых моделей
Рисунок 3 - Сетевая модель данных
в разных отделах, один и тот же служащий может выполнять разные виды работ и один вид работ может выполняться разными служащими.
Классическое описание простой сетевой структуры содержится в предложениях CODASYL (ассоциация, разработавшая язык КОБОЛ). В соответствии с этими предложениями различают понятия тип записи и набор. Запись трактуется как классическая структура данных - запись, а под набором понимается экземпляр поименованной совокупности записей. В наборе выделяется одна запись – владелец и одна или несколько записей – членов набора. По своей сути набор – это поименованное двухуровневое дерево. Пример такого набора приведен на рисунке 4.
Рисунок 4 - Пример набора
Используя наборы можно описывать более сложные структуры данных.
Дерево строится путем объединения нескольких наборов: тип записи – владельца на нижнем уровне дерева должен быть объявлен членом набора более высокого уровня.
Простая сетевая структура строится путем объединения наборов по следующему правилу: запись может быть членом любого количества наборов.
Сложная сетевая структура преобразуется к более простому виду (рисунок 5).
а) фрагмент концептуальной модели;
б) преобразование к простой сетевой структуре.
Рисунок 5 - Пример реализации сложной сетевой структуры