Диго С.М. Базы данных проектирование и использование (1084447), страница 31
Текст из файла (страница 31)
Рис. 3.27. Вид окна Редактор таблиц при работе с DM-моделью
Рис. 3.28. Вид панели инструментов
для многомерной модели
3.4.6. Переход к даталогической модели
На основе физической модели ERWin можно сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Создание схемы базы данных из концептуальной модели называется прямым проектированием (Forward Engineering). Для генерации системного каталога БД следует выбрать пункт меню Tasks/Forward Engineer/Schema Generation или щелкнуть по кнопке 
на панели инструментов. В результате появится окно (рис. 3.29) генерации схемы в выбранной целевой СУБД.
Кнопка Filter позволяет убрать объекты из схемы. Кнопка Preview позволяет просмотреть SQL-скрипт, создаваемый ERWin для генерации системного каталога СУБД. С помощью кнопки Print можно вывести на печать созданный SQL-скрипт. Кнопка Report сохранит тот же скрипт в текстовом файле. Кнопка Generate запускает процесс генерации схемы.
Рис. 3.29. Вид окна генерации схемы
На это следует обратить внимание
1. На построение логической модели базы данных оказывает влияние множество факторов, и все они в комплексе должны быть учтены при создании даталогической модели.
2. Подход к проектированию логической структуры базы данных, рассмотренный для реляционной модели, может быть применен и при проектировании других структурированных баз данных. При этом в алгоритме перехода от ER-модели к модели, поддерживаемой конкретной СУБД, должны быть учтены особенности модели данных целевой СУБД.
3. Поскольку базовая ER-модель является объектной по своей сути, то она может быть использована и при создании объектных баз данных.
4. Использование CASE-средств позволяет улучшить качество разрабатываемых проектов, а при создании крупных корпоративных систем является практически неизбежным.
5. Применение CASE-средств не освобождает проектировщика от понимания не только общей сущности, но и деталей даталогического проектирования.
Контрольные вопросы
1. Что называется даталогическим проектированием?
2. Какая информация является исходной для даталогического проектирования?
3. В чем заключается проектирование логической структуры базы данных для каждого из известных вам классов СУБД или конкретных СУБД?
4. Какие критерии используются для оценки спроектированной базы данных?
5. В каких случаях и для обеспечения каких целей вводятся искусственные идентификаторы?
6. Как отображаются простой объект и его единичные свойства в реляционной базе данных? в других известных вам СУБД?
7. Как отображаются условные свойства объектов в реляционной базе данных? в других известных вам СУБД?
8. Как отображаются множественные свойства объектов в реляционной базе данных? в других известных вам СУБД?
9. Как отображается отношение типа 1:1 между объектами в реляционной базе данных? в других известных вам СУБД? Влияет ли при этом класс принадлежности объектов на число требуемых файлов/таблиц?
10. Как отображается отношение типа 1:М между объектами в реляционной базе данных? в других известных вам СУБД? Влияет ли при этом класс принадлежности объектов на число требуемых файлов/ таблиц?
11. Как отображается отношение типа М:М между объектами в реляционной базе данных? в других известных вам СУБД? Влияет ли при этом класс принадлежности объектов на число требуемых файлов/таблиц?
12. Как отображается в реляционной модели составной объект? в других известных вам СУБД?
13. Как отображается в реляционной модели обобщенный объект?
14. Как отображается в реляционной модели агрегированный объект?
15. Все ли показатели, отображенные в инфологической модели, должны включаться в базу данных?
16. Какие факторы влияют на принятие решения о выборе показателей, хранимых в базе данных?
17. В каком случае надо проводить вертикальное и горизонтальное разбиение файлов/таблиц базы данных?
18. Что в ERWin называется физической моделью?
19. Как можно построить физическую модель в ERWin?
20. В чем состоят отличия физической модели от логической (в ERWin)?
21. Может ли физическая модель содержать элементы (таблицы, поля и др.), которые отсутствовали в логической модели (в ERWin)? Если да, то чем это может быть вызвано?
22. Может ли логическая модель содержать элементы (сущности, атрибуты), которые не переносятся в физическую модель (в ERWin)? Если да, то чем это может быть вызвано?
23. Что называется «целевой СУБД»? Как можно выбрать целевую СУБД?
24. К каким изменениям в физической модели приведет смена целевой СУБД?
25. В каких нотациях может быть построена физическая модель? Чем они отличаются друг от друга?
26. Как можно построить хранилище данных с использованием ERWin?
27. Что представляет собой схема «звезда»?
28. Что в хранилище данных называется таблицей факта? таблицами измерения? «вынесенными» (консольными) таблицами?
Глава 4 ЦЕЛОСТНОСТЬ БАЗЫ ДАННЫХ
4.1. Классификация ограничений целостности
Обеспечение целостности данных является важнейшей задачей при проектировании и эксплуатации систем обработки данных (СОД).
«Проблема целостности состоит в обеспечении ... правильности данных в базе данных в любой момент времени» [14]. Целостность — актуальность и непротиворечивость информации, ее защищенность от разрушения и несанкционированного изменения.
Целостность является одним из аспектов информационной безопасности наряду с доступностью - возможностью с приемлемыми затратами получить требуемую информационную услугу, и конфиденциальностью - защитой от несанкционированного прочтения.
Целостность данных - неотъемлемое свойство базы данных, и ее обеспечение является важнейшей задачей проектирования БнД. Целостность данных описывается набором специальных предложений, называемых ограничениями целостности. Ограничения целостности представляют собой утверждения о допустимых значениях отдельных информационных единиц и связях между ними. Эти ограничения определяются в большинстве случаев особенностями предметной области, хотя могут отражать и чисто информационные (лингвистические) характеристики. Например, если используются цифровые коды для обозначения какой-либо номенклатуры, то ограничения на тип используемых символов для соответствующего атрибута в БД определяются не спецификой предметной области, а просто выбранным способом кодирования, а ограничение, выражающееся в том, что возраст работающего должен быть не менее 16 лет, — трудовым законодательством, т.е. только спецификой предметной области.
При выполнении операций над БД проверяется выполнение ограничений целостности. Действия, приводящие к нарушению подобных ограничений, отвергаются.
Ограничения целостности могут классифицироваться по разным признакам (рис. 4.1).
Ограничения целостности могут относиться к разным информационным объектам: атрибутам (полям), кортежам (строкам, записям), отношениям (таблицам, файлам)*, связям между файлами и т.п.
Рис. 4.1. Общая схема классификации ограничений целостности
1. Поле. Для него чаще всего используются следующие виды ограничений.
1.1. Тип и формат поля. Тип поля определяет допустимые для данного поля символы, а иногда и более жесткие ограничения на допустимые значения (как, например, для полей типа дата или логическое).
1.2. Задание диапазона значений. Обычно используется для числовых полей.
1.2.1. Различают односторонние и двусторонние диапазоны. Первые фиксируют значение только одной из границ (верхней или нижней), вторые - обеих границ. Так, например, до определенного времени в нашей стране ограничивался как нижний, так и верхний предел заработной платы. Это пример двустороннего закрытого диапазона. Затем ограничение по верхнему пределу было снято: заработная плата не может быть меньше установленного минимума, но максимальное ее значение законодательно не определено — ограничение стало односторонним.
1.2.2. Диапазоны бывают открытые и закрытые. Односторонний диапазон всегда является открытым, двусторонний может быть как открытым, так и закрытым.
Двусторонний диапазон будет открытым, если допустимые значения меньше «левой» границы и больше «правой» (рис. 4.2). Задание двусторонних открытых диапазонов используется гораздо реже, чем закрытых. Некоторые СУБД поддерживают высокоуровневые средства задания двусторонних закрытых диапазонов и не поддерживают - открытых. Пример открытого диапазона: орган социального обеспечения поддерживает базу данных, содержащих записи о людях моложе 16 лет или старше 60.
Рис. 4.2. Графическая иллюстрация понятий открытого (а)
и закрытого (б) двустороннего диапазона
1.3. Признак непустого поля. Характеризует недопустимость пустого значения поля в БД. Так, например, в таблице, содержащей сведения о сотрудниках, поля «Фамилия», «Имя», «Отчество», «Оклад» должны обязательно иметь какое-то значение, а у поля «Ученая_степень» значение может отсутствовать.
1.4. Задание домена. Поле может принимать значение из заданного множества. Множество возможных значений какого-либо атрибута называется доменом. Домен может задаваться перечислением входящих в него значений (например, значением поля «Пол» может быть только либо «мужской» либо «женский»; значением поля «Должность» для профессорско-преподавательского состава может быть: «ассистент», «старший преподаватель», «доцент» и «профессор») или алгоритмом вычисления допустимых значений (как это обычно происходит для полей типа «Дата»). Последний из приведенных примеров свидетельствует не только о возможностях СУБД по поддержанию целостности данных, но и о важности процедуры выбора типа данных при проектировании баз данных.
Следует обратить внимание, что термин «домен» здесь используется не как сугубо реляционный, а для обозначения множества возможных значений какого-либо атрибута безотносительно к используемой модели данных.
1.5. Специфическим ограничением на значение поля является признак его уникальности. Это ограничение проверяет допустимость значения данного поля, но при этом просматривается вся таблица (файл). Поэтому, с одной стороны, данное ограничение правильнее было бы отнести к ограничениям на таблицу. Но, с другой стороны, ограничение на уникальность поля проверяется сразу после ввода значения конкретного поля, в отличие от большинства других ограничений целостности на таблицу.
Признак уникальности поля тесно связан с понятием ключа, но уже последнего, поскольку ключ может быть представлен не только одним полем, а совокупностью полей (составной ключ). Уникальное поле является вероятным ключом данного отношения. При наличии нескольких вероятных ключей один из них должен быть выбран в качестве первичного ключа. Поле, выбранное в качестве первичного ключа, не должно иметь пустых значений. Не все СУБД поддерживают концепцию ключа, т.е. позволяют определять ключ при описании БД. Некоторые СУБД для каждого файла (таблицы) требуют обязательно определять ключ при описании базы данных. Другие СУБД (например, Access), в принципе поддерживая концепцию ключа, разрешают создавать таблицы, в которых ключ не задан.
Ограничение на уникальность чаще всего возникает при отображении в базе данных каких-то объектов, и уникальное поле является идентификатором этого объекта. Поэтому это ограничение целостности иногда называется ограничением целостности объекта (сущности).
1.6. Очень важным видом ограничений целостности являются функциональные зависимости. Информацию об имеющих место в данной предметной области функциональных зависимостях можно извлечь из инфологической модели (см. разд. 4.2). Эта информация используется и при проектировании базы данных, и для контроля целостности при ее функционировании. Если БД спроектирована правильно, т.е. она находится в 4-й нормальной форме, то, определяя ключи и вероятные ключи отношений, тем самым определяются и имеющиеся функциональные зависимости между атрибутами.
1.7. Рассмотренные выше ограничения определяли проверки значения поля вне зависимости от того, вводится это значение впервые или корректируются имеющиеся в базе данных значения. Ограничения, которые используются только при проверке допустимости корректировки, называют ограничениями перехода (или динамическими ограничениями). Например, если в базе данных имеются поля «Возраст_сотрудника», «Стаж_работы» и т.п., то при корректировке значения этих полей могут только увеличиваться. В аспекте правильности проектирования БД приведенные выше для иллюстрации поля, особенно поле «Возраст_сотрудника», лучше вообще не хранить в базе данных, а получать расчетным путем. Это не только существенно упростит ведение базы данных, но и облегчит процесс обеспечения целостности данных.
Другим примером ограничения перехода является корректировка поля «Семейное_положение». Так, значение «вдовец» может быть исправлено только на «женат», а «холост» не может быть исправлен на «разведен» и т.п.
Ограничение целостности может относиться как к реальному, так и к виртуальному полю, т.е. полю, которое в явном виде в таблице не хранится (например, если в БД фиксируется только поле «Дата__рождения», а ограничение накладывается на возраст). Последнее порождает дополнительные сложности. Так, в рассматриваемом примере значение свойства «возраст» в явном виде в БД не хранится - значит, надо разрабатывать специальную процедуру проверки соблюдения ограничения в каждый момент времени и решать вопрос о периодичности использования этой процедуры для проверки БД. Когда проверка происходит в момент ввода данных, то она играет двоякую роль: контроль правильности ввода данных и соответствие человека, о котором вводятся данные, предъявляемым к нему требованиям. При периодической проверке данного ограничения после ввода данных происходит проверка соответствия самой предметной области установленным требованиям.
Проверка соблюдения выполнения ограничений целостности, естественно, замедляет процесс обработки данных. Поэтому иногда бывает полезным определить, могут ли внесенные изменения базы данных привести к нарушению тех или иных ограничений целостности, и проводить контроль только в случае, когда такие нарушения потенциально могут возникнуть. Например, в предметной области может быть ограничение, заключающееся в том, что зарплата начальника не может быть ниже зарплаты его подчиненных. Тогда в случае увеличения зарплаты начальника соблюдение этого ограничения проверять не надо, а в случае уменьшения - надо.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
