Файл: Систем управления.pdf

Простота проектирования
Вероятно, потребуется квалифицированная помощь, особенно при определении необходимых структур данных и при разработке связанных с ними прикладных программ
Проектирование могут выполнить только опытные специалисты-эксперты
Большинство пользователей (включая конечных пользователей) легко поймут логическую структуру данных, а потому смогут спроектировать базу данных и отобразить её на физические структуры. К сожалению, недостаточное знание методов проектирования баз данных может привести к созданию слабых, неэффективных и негибких макетов
Доступ к базе данных
Стандартные методы доступа посредством API: приложение содержит встроенные вызовы процедур для работы с
СУБД, команды обрабатывают записи последовательно, по одной, хотя потенциально они могут оказывать влияние и на другие записи.
Дополнительные программные конструкции необходимы для навигации по базе данных и обработки наборов записей
Здесь также доступ осуществляется исключительно посредством API. Команды обрабатывают записи по одной, но при этом они могут влиять и на зависимые записи.
Благодаря использованию специальных команд навигации по базе данных пользователь может перемещаться к разным местам иерархической структуры.
Для обработки наборов записей могут потребоваться специальные программные конструкции
Доступ может варьироваться от использования API до таких интерактивных языков, как SQL или QBE.
Языки запросов позволяют конечным пользователям опрашивать базу данных в произвольной манере.
Кроме того, SQL-команды могут внедряться в прикладные программы
Стандарты
Для CODASYL- совместимой модели данных существует набор стандартных концепций, хотя между разными реализациями есть некоторые различия
Для иерархической модели данных не существует строгого набора стандартных концепций, а реализации этой модели не соответствуют какому- либо особому стандарту
Для реляционных моделей данных существует набор стандартных концепций, хотя между разными реализациями есть некоторые различия
Приложение 4. Пример мифологического проекта базы данных
В [5] приведен отличный («классический») пример построения инфологической модели базы данных
«Питание», где должна храниться информация о блюдах (рис.П.4.1), их ежедневном потреблении, продуктах, из которых приготавливаются эти блюда, и поставщиках этих продуктов. Информация предназначена для использования поваром и руководителем небольшого предприятия общественного питания, а также его посетителями.
125

Рис. П.4.1 Пример кулинарного рецепта
С помощью потенциальных пользователей выделены следующие объекты и характеристики проектируемой базы данных.
1. Блюда, для описания которых нужны данные, входящие в их кулинарные рецепты: номер блюда
(например, из книги кулинарных рецептов), название блюда, вид блюда (закуска, суп, горячее и т.п.), рецепт (технология приготовления блюда), выход (вес порции), название, калорийность и вес каждого продукта, входящего в блюдо.
2. Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки.
3. Ежедневное потребление блюд (расход): блюдо, количество порций, дата.
Анализ объектов позволяет выделить:

стержни Блюда, Продукты и Города;

ассоциации Состав (связывает Блюда с Продуктами) и Поставки (связывает Поставщиков с
Продуктами);

обозначение Поставщики;

характеристики Рецепты и Расход.
ER-диаграмма модели показана на рис. П.4.2 а модель на языке ЯИМ имеет следующий вид.
В этих моделях Блюдо, Продукт и Поставщик – наименования, а БЛ, ПР и ПОС – цифровые коды блюд, продуктов и организаций, поставляющих эти продукты.
126

Рис. П.4.2. Инфологическая модель базы данных «Питание»
Приложение 5. Обобщенная методика проектирования реляционных баз данных
Процесс разработки баз данных включает три фазы:
1) концептуальное (инфологическое) проектйрование;
2) логическое проектирование;
3) физическое проектирование [7, 17].
ЭТАП 1
Создание локальной концептуальное модели данных исходя из представлений о предметной
боласти каждого из типов пользователей
Построение локальной концептуальной модели данных организации с точки зрения представления о функционировании организации каждого из существующих типов пользователей.
1.1. Определение типов сущностей
Определение основных типов сущностей, присутствующих в представлении данного пользователя о предметной области приложения. Документирование выделенных типов сущностей.
1.2. Определение типов связей
Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе. Определение кардинальности связей и ограничений участия их членов.
Документирование типов связей. При необходимости могут использоваться диаграммы «сущность связь» (ER-диаграммы).
1.3. Определение атрибутов и связывание их с типами сущностей и связей
Связывание атрибутов с соответствующими типами оущностей или связей. Идентификация простых и составных атрибутов. Документирование сведений об атрибутах.
1.4. Определение доменов атрибутов
Определение доменов для всех атрибутов в каждой локальной концептуальной модели данных.
127

Документирование сведений о доменах атрибутов.
1.5. Определение атрибутов, являющихся потенциальными и первичными ключами
Определение потенциального ключа для каждого типа сущности; если таких ключей окажется несколько, выбор среди них первичного ключа. Документирование сведений о первичных и альтернативных ключах для каждой сильной сущности.
1.6. Специализация или генерализация типов сущностей (необязательно)
Определение суперклассов и подклассов для типов сущностей (при необходимости).
1.7. Создание диаграммы «сущность-связь»
Разработка диаграмм «сущность-связь» (ER-диаг-рамм), содержащих концептуальное отражение представлений пользователей о предметной области приложения.
1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями
Обсуждение локальных концептуальных моделей данных с конечными пользователями для получения подтверждений того, что данная модель корректно отражает представления пользователей о приложении и организации.
ЭТАП 2
Построение и проверка локальной логической модели данных на основе представлений о
предметной области каждого из типов пользователей
Построение логической модели данных на основе концептуальной модели данных, отражающей представление отдельного пользователя о предметной области приложения, проверка полученной модели с помощью методов нормализации и контроля возможности выполнения транзакций.
2.1. Преобразование локальной концептуальной модели данных в локальную логическую модель
Доработка локальных концептуальных моделей с целью удаления из них нежелательных элементов и преобразование полученных моделей в локальные логические модели данных. Удаление связей типа
M:N, сложных связей, рекурсивных связей, множественных атрибутов, связей с атрибутами и избыточных связей. Перепроверка связей типа 1:1.
2.2. Определение набора отношений исходя из структуры локальной логической модели данных
Определение на основе локальных логических моделей данных набора отношений, необходимого для представления сущностей и связей, входящих в представления отдельных пользователей о предметной области приложения. Документирование сведений о новых первичных или потенциальных ключах, которые были определены в процессе создания отношений на основе логической модели данных.
2.3. Проверка модели с помощью правил нормализации
Проверка локальной логической модели данных с использованием технологии нормализации. Целью выполнения этого этапа является получение гарантий того, что каждое из отношений, созданных на основе дорической модели данных, отвечает, по крайней мере, требованиям НФБК (нормальной формы
Бойса-Кодда).
2.4. Проверка модели в отношении транзакций пользователей
Цель выполнения этого этапа – убедиться в том, что локальная логическая модель данных позволяет
128

выполнить все транзакции, предусмотренные данным представлением пользователя.
2.5. Создание диаграмм «сущность-связь»
Создание диаграмм «сущность-связь» (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.
2.6. Определение требований поддержания целостности данных
Определение ограничений, налагаемых на отдельные элементы представлений пользователей требованиями сохранения целостности данных. Сюда относятся определение обязательности наличия данных, установление ограничений для доменов атрибутов, определение требований сохранения целостности сущностей и поддержки ссылочной целостности данных, а также учет требований (бизнес- правил) данной организации. Документирование всех установленных ограничений.
2.7. Обсуждение разработанных локальных логических моделей данных с конечными
пользователями
Назначение данного этапа – убедиться в том, что созданные локальные модели данных точно отражают представления пользователей о предметной области приложения.
ЭТАП 3
Создание и проверка глобальной логической модели данных.
Объединение отдельных локальных логических моделей данных в единую глобальную логическую модель данных, представляющую ту часть организации, которая охватывается данным приложением.
3.1. Слияние локальных логических моделей данных в единую глобальную модель данных
Объединение отдельных локальных логических моделей данных в единую глобальную логическую модель данных организации. В круг решаемых при этом задач включены следующие:

анализ имен сущностей и их первичных ключей;

анализ имен связей;

слияние общих сущностей из отдельных локальных моделей;

включение (без слияния) сущностей, уникальных для каждого локального представления;

слияние общих связей из отдельных локальных моделей;

включение (без слияния) связей, уникальных для каждого локального представления;

проверка на наличие пропущенных сущностей и связей;

проверка корректности внешних ключей;

проверка соблюдения ограничений целостности;

выполнение чертежа глобальной логической модели данных;

обновление документации.
3.2. Проверка глобальной логической модели данных
Проверка глобальной логической модели данных с помощью методов нормализации и контроль возможности выполнения требуемых транзакций. На этом этапе выполняются действия, аналогичные тем, которые производились на этапах 2.3 и 2.4 при проверке каждой из локальных логических моделей данных.
3.3. Проверка возможностей расширения модели в будущем
Определение вероятности внесения каких-либо существенных изменений в созданную модель данных в обозримом будущем и оценка того, насколько данная модель приспособлена для внесения подобных изменений.
129

3.4. Создание окончательного варианта диаграммы «сущность-связь»
Создание окончательного варианта диаграммы «сущность-связь», представляющей глобальную логическую модель данных организации.
3.5. Обсуждение глобальной логической модели данных с пользователями
Цель данного этапа – убедиться в том, что созданная глобальная логическая модель данных адекватно отражает моделируемую часть информационной структуры организации.
ЭТАП 4
Перенос глобальной логической модели данных в среду целевой СУБД
Создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных.
4.1. Проектирование таблиц базы данных в среде целевой СУБД
Определение способа представления всех выделенных в глобальной логической модели данных отношений в виде таблиц целевой СУБД. Документирование результатов проектирования таблиц.