Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое.
Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.
Атрибут – поименованная характеристика сущности.
Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д.,однако каждому экземпляру сущности присваивается только одно значение атрибута.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).
Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь) (рис.1).
В них сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками,
атрибуты – помеченными овалами,
а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.
Между двумя сущностям, например, А и В возможны четыре вида связей.
Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:
Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.
Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.
Квартира может пустовать, в ней может жить один или несколько жильцов.
Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).
П
ример: Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможныхпредставления такой связи:
Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи:
м
ножество связей между одними и теми же сущностями
(пациент, имея одного лечащего врача, может иметь также несколько врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать несколько других пациентов);
т
ренарные связи
(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);
связи более высоких порядков, семантика (смысл) которых иногда очень сложна.
В приведенных примерах для повышения иллюстративности рассматриваемых связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграммах. Так, ввод лишь нескольких основных атрибутов в описание брачных связей значительно усложнит ER-диаграмму. В связи с этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:
СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)
АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...]
(атрибут 1, атрибут 2, ..., атрибут n)
где S – степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью подчеркивания.
Так, рассмотренный выше пример множества связей между сущностями, может быть описан на ЯИМ следующим образом:
Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)
Пациент (Регистрационный_номер, Номер койки, Фамилия,
Имя, Отчество, Адрес, Дата рождения, Пол)
Лечащий_врач [Врач 1, Пациент M]
(Номер_врача, Регистрационный_номер)
Консультант [Врач M,Пациент N]
(Номер_врача, Регистрационный_номер).
Рис. 1. Примеры ER-диаграмм
Для выявления связей между сущностями необходимо, как минимум, определить сами сущности. Но это не простая задача, так как в разных предметных областях один и тот же объект может быть сущностью, атрибутом или ассоциацией.
Что же такое "связь"? В ER-диаграммах это линия, соединяющая геометрические фигуры, изображающие сущности, атрибуты, ассоциации и другие информационные объекты. В тексте же этот термин используется для указания на взаимозависимость сущностей. Если эта взаимозависимость имеет атрибуты, то она называется ассоциацией.
Классификация сущностей
В терминологии сущностей К.Дейт определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.
Стержневая сущность (стержень) – это независимая сущность .
В рассмотренных ранее примерах стержни – это "Студент", "Квартира", "Мужчины", "Врач", "Брак" и другие, названия которых помещены в прямоугольники.
Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности . Ассоциации рассматриваются как полноправные сущности;
они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;
могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь. Например, ассоциации "Брак" из примеров содержат ключевые атрибуты "Код_М", "Код_Ж" и "Табельный номер мужа", "Табельный номер жены", а также уточняющие атрибуты "Номер свидетельства", "Дата регистрации", "Место_регистрации", "Номер записи в книгу ЗАГС" и т.д.
Характеристическая сущность (характеристика) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства. Муж может иметь несколько жен , книга – несколько характеристик переиздания (исправленное, дополненное, переработанное, ...) и т.д.
Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.
Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид:
ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...)
{СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.
Расширим также язык ER-диаграмм, введя для изображения характеристики трапецию (рис. 2).
Рис. 2. Элементы расширенного языка ER-диаграмм
Обозначающая сущность или обозначение – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.
Обозначения используют для хранения повторяющихся значений больших текстовых атрибутов: "кодификаторы" изучаемых студентами дисциплин, наименований организаций и их отделов, перечней товаров и т.п.
Описание обозначения внешне отличается от описания характеристики только тем, что обозначаемые сущности заключается не в фигурные скобки, а в квадратные:
ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК
ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].
Как правило, обозначения не рассматриваются как полноправные сущности, хотя это не привело бы к какой-либо ошибке.
Обозначения и характеристики не являются полностью независимыми сущностями, поскольку они предполагают наличие некоторой другой сущности, которая будет "обозначаться" или "характеризоваться". Однако они все же представляют собой частные случаи сущности и могут, конечно, иметь свойства, могут участвовать в ассоциациях, обозначениях и иметь свои собственные (более низкого уровня) характеристики. Подчеркнем также, что все экземпляры характеристики должны быть обязательно связаны с каким-либо экземпляром характеризуемой сущности. Однако допускается, чтобы некоторые экземпляры характеризуемой сущности не имели связей. Правда, если это касается браков, то сущность "Мужья" должна быть заменена на сущность "Мужчины" (нет мужа без жены).
Переопределим теперь стержневую сущность как сущность, которая не является ни ассоциацией, ни обозначением, ни характеристикой. Такие сущности имеют независимое существование, хотя они и могут обозначать другие сущности, как, например, сотрудники обозначают отделы.
О первичных и внешних ключах
Напомним, что ключ или возможный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.
Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ.
При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов.
Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Так, для идентификации студента можно использовать либо уникальный номер зачетной книжки, либо набор из фамилии, имени, отчества, номера группы и может быть дополнительных атрибутов, так как не исключено появление в группе двух студентов (а чаще студенток) с одинаковыми фамилиями, именами и отчествами. Плохо также использовать в качестве ключа не номер блюда, а его название, например, " Закуска из плавленых сырков "Дружба" с ветчиной и соленым огурцом" или "Заяц в сметане с картофельными крокетами и салатом из красной капусты".
Не допускается, чтобы первичный ключ стержневой сущности (любой атрибут, участвующий в первичном ключе) принимал неопределенное значение. Иначе возникнет противоречивая ситуация: появится не обладающий индивидуальностью, и, следовательно не существующий экземпляр стержневой сущности. По тем же причинам необходимо обеспечить уникальность первичного ключа.
Теперь о внешних ключах:
Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.
Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.
Связь между первичными и внешними ключами сущностей иллюстрируется рис. 3.
Рис. 3. Структуры: а - ассоциации; б - обозначения (характеристики)
Здесь для обозначения любой из ассоциируемых сущностей (стержней, характеристик, обозначений или даже ассоциаций) используется новый обобщающий термин "Цель" или "Целевая сущность".
Таким образом, при рассмотрении проблемы выбора способа представления ассоциаций и обозначений в базе данных основной вопрос, на который следует получить ответ: "Каковы внешние ключи?". И далее, для каждого внешнего ключа необходимо решить три вопроса:
1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом? В случае поставок это, вероятно, невозможно – поставка, осуществляемая неизвестным поставщиком, или поставка неизвестного продукта не имеют смысла. Но в случае с сотрудниками такая ситуация однако могла бы иметь смысл – вполне возможно, что какой-либо сотрудник в данный момент не зачислен вообще ни в какой отдел. Заметим, что ответ на данный вопрос не зависит от прихоти проектировщика базы данных, а определяется фактическим образом действий, принятым в той части реального мира, которая должна быть представлена в рассматриваемой базе данных. Подобные замечания имеют отношение и к вопросам, обсуждаемым ниже.
2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку. Существует три возможности:
КАСКАДИРУЕТСЯ Операция удаления "каскадируется" с тем, чтобы удалить также поставки этого поставщика.
ОГРАНИЧИВАЕТСЯ Удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается.
УСТАНАВЛИВАЕТСЯ Для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.
3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении:
КАСКАДИРУЕТСЯ Операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ впоставках этого поставщика.
ОГРАНИЧИВАЕТСЯ Обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.
УСТАНАВЛИВАЕТСЯ Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.
Таким образом, для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющих этот внешний ключ, и целевую таблицу, которая идентифицируется этим ключом, но также и ответы на указанные выше вопроса (три ограничения, которые относятся к этому внешнему ключу).
Наконец, о характеристиках – обозначающих сущностях, существование которых зависит от типа обозначаемых сущностей. Обозначение представляется внешним ключом в таблице, соответствующей этой характеристике. Но три рассмотренные выше ограничения на внешний ключ для данного случая должны специфицироваться следующим образом:
NULL-значения не допустимы
УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ
ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ
Указанные спецификации представляют зависимость по существованию характеристических сущностей.
Ограничения целостности
Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).
Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).
Выделяют три группы правил целостности:
Целостность по сущностям;
Целостность по ссылкам;
Целостность, определяемая пользователем.
Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.
Значение внешнего ключа должно либо:
быть равным значению первичного ключа цели;
быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.
Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется:
уникальность тех или иных атрибутов,
диапазон значений (экзаменационная оценка от 2 до 5),
принадлежность набору значений (пол "М" или "Ж").
О построении инфологической модели
Основная сложность восприятия рекомендаций, приведенных в методических рекомендациях, чисто психологического плана.
Действительно, для определения перечня и структуры хранимых данных надо собрать информацию о реальных и потенциальных приложениях, а также о пользователях базы данных, а при построении инфологической модели следует заботиться лишь о надежности хранения этих данных, напрочь забывая о приложениях и пользователях, для которых создается база данных.
Это связано с абсолютно различающимися требованиями к базе данных прикладных программистов и администратора базы данных. Первые хотели бы иметь в одном месте (например, в одной таблице) все данные, необходимые им для реализации запроса из прикладной программы или с терминала. Вторые же заботятся о исключении возможных искажений хранимых данных при вводе в базу данных новой информации и обновлении или удалении существующей. Для этого они удаляют из базы данных дубликаты и нежелательные функциональные связи между атрибутами, разбивая базу данных на множество маленьких таблиц. Так как многолетний мировой опыт использования информационных систем, построенных на основе баз данных, показывает, что недостатки проекта невозможно устранить любыми ухищрениями в программах приложений, то опытные проектировщики не позволяют себе идти навстречу прикладным программистам (даже тогда, когда они сами являются таковыми).
Большинство людей предпочитает учиться на собственных ошибках, все же еще раз советуем неопытным проектировщикам баз данных:
четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);
помнить, что, как правило, база данных является информационной основой не одного, а нескольких приложений, часть их которых появится в будущем;
плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.
Рассмотрим выделение информационных объектов на примере предметной области "Учебный процесс".
Описание предметной области.
Пусть необходимо построить базу данных, содержащую информацию об учебном процессе текущего семестра.
Документами справочной информации могут быть:
• списки студентов групп,
• перечень изучаемых предметов,
• преподавательский состав кафедр, обеспечивающих учебный процесс,
• сведения о лекционных и практических занятиях в каждой из групп,
• результаты сдачи экзаменов (зачетов) по каждому из проведенных занятий.
В результате анализа предметной области выявляются документы-источники данных для создания базы данных.
Справочная информация содержится в документах: "Список студентов группы", "Список преподавателей кафедры", "Список изучаемых предметов". На рисунках приведены примеры форм справочных документов.
Учетная информация по учебному процессу может быть представлена в планах проведения занятии в группах на текущий семестр, содержащих перечень изучаемых предметов с часами лекционных и практических занятий, а также в заполненных экзаменационных ведомостях.
Экзаменационная ведомость
Название предмета _______ Группа
Преподаватель __________
Вид сдачи _____
Выделение объектов справочной информации
Определим функциональные зависимости между реквизитами документа "Список преподавателей кафедры", предварительно включив их перечень в таблицу .
Из анализа документа очевидно, что реквизиты Название кафедры (НКАФ), Телефон (ТЕЛ), Заведующий (ЗАВ) являются описательными, и каждый из них зависит только от ключевого реквизита — Код кафедры (ККАФ), который в то же время выполняет роль общего идентификатора списка преподавателей кафедры.
Реквизиты — Фамилия И.О. (ФИО), Уч. степень (СТ), Уч. звание (3В) однозначно определяются ключевым реквизитом Таб. номер (ТАБН) преподавателя.
Обратим внимание на связь реквизитов ККАФ и ТАБН. В этой функциональной связи выполняется необходимое условие — одному значению ключа ТАБН соответствует одно значение зависимого реквизита ККАФ. Этот реквизит играет роль описательного реквизита для преподавателя. Если такая связь не установлена, то все множество реквизитов документа разделится на два не связанных между собой подмножества, а это нелогично для реквизитов одного документа.
Все установленные функциональные зависимости реквизитов документа "Список преподавателей кафедры" отражены в табл. 2.1.
Внимание! Реквизит ККАФ одновременно выступает в роли описательного реквизита в одной связи и ключевого — в другой связи. Таким образом здесь мы сталкиваемся с транзитивной зависимостью. Реквизит НКАФ транзитивно зависит от ТАБН через ККАФ. Тем не менее специальных действий по расщеплению этой зависимости не потребуется при использовании приведенных правил.
Выберем по функциональным связям реквизиты, зависимые от каких либо других реквизитов и укажем для них ключевые реквизиты.
Так при просмотре списка реквизитов сверху находим первый зависимый (описательный) реквизит ККАФ и устанавливаем его ключевой ТАБН. Далее находим второй зависимый (описательный) реквизит НКАФ и устанавливаем его ключевой ККАФ. Аналогично находим описательный ТЕЛ и устанавливаем его ключевой ККАФ и так далее. Выявленное соответствие описательных и ключевых реквизитов представлено ниже в таблице.
Таблица 2. 2. Соответствие описательных и ключевых реквизитов документа "Список преподавателей кафедры"
Сгруппируем реквизиты, зависимые от одних и тех же ключевых реквизитов, и объединим их с ключевыми реквизитами в один информационный объект.
Результат группировки реквизитов документа "Список преподавателей кафедры" приведен в табл. 2. 3.
П- простой. У- уникальный
Таким образом на основе анализа документа "Список преподавателей кафедры" выделены два информационных объекта — КАФЕДРА и ПРЕПОДАВАТЕЛЬ.
Аналогично рассмотренному выше может быть выполнен анализ документа "Список студентов группы" и будут выделены другие объекты справочной информации — ГРУППА, СТУДЕНТ .
Объект ГРУППА характеризуется числом студентов в группе, средним проходным баллом. Для однозначной идентификации группы используется ее номер.
Объект СТУДЕНТ имеет описательные реквизиты: фамилию, гол рождения, адрес проживания. Для идентификации студента может быть выбрана фамилия. Однако, учитывая возможность повторений, лучше в качестве идентификатора студента в группе рассматривать его порядковый номер в списке группы. Тогда для уникальной идентификации среди всех студентов ВУЗа можно использовать составной ключ из номера группы и порядкового номера в группе. Такой идентификатор позволяет в то же время явно определить принадлежность студента к группе. К объектам справочной информации относится также информационный объект ПРЕДМЕТ, который легко выявляется на основе интуитивного подхода.
Информационный объект ПРЕДМЕТ характеризуется наименованием, общим количеством часов, количеством часов лекций, практических занятий, числом семестров и т. п. В качестве идентификатора предмета вместо наименования целесообразно ввести уникальный код предмета. Это облегчит реализацию в базе данных связей этого объекта с другими, в которых необходима ссылка на предмет.
Описание информационных объектов, которые наряду с объектами ПРЕПОДАВАТЕЛЬ и КАФЕДРА относятся к справочной информации, представлено в табл. 2. 4.
Таким образом вся совокупность объектов справочной информации представлена в табл. 2. 3, 2. 4.
Выделение объектов учётной информации
Документ "План проведения занятий в группе" (рис. 2. 5) содержит сведения о занятиях, проводимых в каждой группе в текущем семестре. ЧАСЫ — это основная количественная характеристика занятия, т. е. описательный реквизит. Соответственно он является реквизитом, зависимым от идентификаторов занятия: номера группы, кода изучаемого предмета, идентификатора преподавателя и вида занятий, т. к. учёт ведется отдельно по лекциям и практическим занятиям.
Кроме того к описательным реквизитам занятия можно отнести расчетный реквизит — средний балл в группе по занятию, если его хранить в базе данных. В результате анализа взаимосвязей реквизитов этого документа можно выделить новый информационный объект ИЗУЧЕНИЕ.
На основе анализа документа "Экзаменационная ведомость" может быть выделен другой объект учетной информации — УСПЕВАЕМОСТЬ.
Полный состав объектов учетной информации представлен в табл. 2. 5.
Информационный объект УСПЕВАЕМОСТЬ обеспечивает хранение в базе данных информации об итоговых оценках студента за семестр по каждому виду занятия, отображенному в объекте ИЗУЧЕНИЕ.
Соответственно такая оценка определяется с одной стороны идентификатором студента (НГ+ НС), а с другой стороны идентификатором занятия (НГ+ КП+ ТАБН+ ВИДЗ).
Таким образом их объединение образует уникальный идентификатор объекта УСПЕВАЕМОСТЬ.
После проектирования таблиц необходимо определить и обозначить связи между ключевыми атрибутами объектов, как показано на схеме связей базы данных «Учебный процесс» (рис.4), что и является инфологической моделью, построенной по схеме «таблицы-связи»:
Р
ис.4 Инфологическая модель базы данных «Учебный процесс»
1.2.2 Даталогическая модель
Даталогическая модель является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Эта модель строится в терминах информационных единиц, допустимых в той конкретной СУБД, в среде которой мы проектируем базу данных. Этап создания даталогической модели называется даталогическим проектированием. Описание логической структуры базы данных на языке СУБД называется схемой.
Хотя даталогическое проектирование является логической структурой базы данных, на него влияют возможности физической организации данных, представляемые конкретной СУБД. Поэтому знание особенностей физической организации данных является полезным при проектировании логической структуры.
Логическая структура базы данных, а также сама заполненная данными база данных является отображением реальной предметной области. Поэтому на выбор проектных решений самое непосредственное влияние оказывает специфика отображаемой предметной области, отраженная в инфологической модели.
Для реляционной базы данных проектирование логической структуры заключается в том, чтобы разбить всю информацию по файлам (отношениям), а также определить состав полей (атрибутов) для каждого из этих файлов.
Одно из требований — реляционная база данных должна быть нормализована. Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении к третьей нормальной форме (или к нормальной форме Бойса-Кодда).
Нормализацией называется формальная процедура, в ходе которой атрибуты данных группируются в таблицы, а таблицы группируются в базу данных (БД).
Анализ предметной области обычно осуществляется на основании известных сведений о ней с учетом целей проектирования программной системы.
Базами данных называют электронные хранилища информации, доступ к которым осуществляется с помощью одного или нескольких компьютеров.
Обычно БД создается для хранения и доступа к данным, содержащим сведения о некоторой предметной области, т.е. некоторой области человеческой деятельности или области реального мира.
Для реляционной БД проектирование логической структуры заключается в том, чтобы разбить всю информацию по файлам (по отношениям), а также определить состав полей (атрибутов) для каждого из этих файлов
Единицей, хранящейся в БД информации, является таблица. Каждая таблица представляет собой совокупность строк и столбцов, где строки соответствуют экземпляру, а столбцы - атрибутам (признакам, характеристикам, параметрам объекта, события, явления).
В терминах БД столбцы таблицы называются полями, а ее строки - записями.
Нормализация выполняется поэтапно. Первые три шага были описаны доктором Э.Ф. Коддом в статье "Дальнейшая нормализация реляционной модели базы данных" в 1972г.
Первая нормальная форма (1НФ). Для нее требуется, чтобы таблица была плоской и не содержала повторяющихся групп. У плоской таблицы есть только две характеристики - длина (количество записей или строк) и ширина (количество полей или столбцов). Такая таблица не должна содержать ячеек, включающих несколько значений.
Никакую из систем управления базами данных (СУБД) не удовлетворяет только 1НФ, так как в этом случае необходимо определить большое число полей, многие из которых остаются в основном пустыми. Избыточные данные могут послужить причиной проблем целостности и снижение эффективности при внесении изменений, поэтому подобных решений при проектировании баз данных необходимо избегать.
Вторая нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен.
В каждой таблице БД может существовать первичный ключ - поле или набор полей, однозначно идентифицирующий запись.
Значение первичного ключа в таблице БД должно быть уникальным, т.е. в таблице не должно существовать двух и более записей с одинаковым значением первичного ключа.
Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц. 2НФ позволяет удалить большую часть повторяющихся данных, которые часто остаются после первого этапа нормализации.
Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.
Отношение находится в четвертой нормальной форме (4НФ), если в нем не присутствуют функциональные многозначные зависимости. Для 4НФ требуется, чтобы в одной таблице не содержались независимые элементы данных, если между ними существует отношение "многие-ко-многим".
Если в отношении имеется много функциональных зависимостей, 4НФ не устраняет избыточность, то применяют пятую нормальную форму (ЗНФ).
Разложение отношений из 4НФ в пятую нормальную форму должно быть выполнено так, чтобы каждая проекция, полученная из 4НФ, содержала не менее одного возможного ключа и хотя бы один неключевой атрибут из исходного отношения. Для 5НФ требуется, чтобы можно было восстановить исходную таблицу на основе информации таблиц, на которые она была разбита. Кроме того, необходимо, чтобы таблицы соответствовали ЗНФ, а при наличии отношений "многие-ко-многим" - 4НФ.
Для большинства существующих СУБД необходимо представить проект базы данных в ЗНФ, так как этого вполне достаточно практически для всех обычных приложений. При разработке исключительно больших систем, когда необходимо максимальное сокращение объемов хранимых данных, желательно произвести дальнейшую нормализацию. Но в этом случае можно столкнуться с недостатками нормализации. Поскольку порог человеческого восприятия не позволяет одновременно анализировать большое число объектов с учетом их взаимосвязей, можно утверждать, что с увеличением числа нормализованных таблиц уменьшается целостное восприятие базы данных как системы взаимосвязанных данных. Другим недостатком нормализованной базы данных является необходимость считывать связанные данные из нескольких таблиц при выполнении одного запроса.
Основным источником информации о данной предметной области является, например, личная карточка студента, личная карточка преподавателя, семестровые ведомости, учебный план, структура университета, заявление на оплату рабочего времени.
При заполнении личной карточки студента используются следующие документы: паспорт, трудовая книжка, военный билет, документ об образовании. В итоге получили следующую реляционную схему, приведенную к ЗНФ:
Адрес (Код, Индекс, Область_край, Населенный пункт, Улица, Дом, Телефон, Физическое лицо)
Аттестат (Код, Номер, Серия, Что закончил, Год окончания, Физическое лицо)
Вид документа (Код, Название)
Вид экзамена (Код, Название)
Вкладыш к диплому (Код, Номер, Серия, Университет, Факультет, Специальность, Год окончания, Физическое лицо)
Выписка из зачетки (Код, Университет, Факультет, Специальность, Год поступления, Физическое лицо)
Группа (Код, Форма обучения, Специальность, Курс, Физическое лицо)
Дисциплина (Код, Название)
Документ (Код, Номер, Дата, Примечание, Вид документа, Группа, Физическое лицо)
Категории (Код, Название)
Курс (Код, Название курса, Номер курса)
Национальность (Код, Название)
Подразделение (Код, Название, Владелец)
Подразделение обучает (Код, Подразделение, Специальность)
Семестр (Код, Номер семестра, Название семестра, Курс)
Семестровая ведомость (Код, Физическое лицо (студент), Дисциплина, Оценка, Вид экзамена, Дата сдачи, Физическое лицо (преподаватель), Семестр)
Специальность (Код, Название, Краткое название)
Трудовая книжка (Код, Последнее место работы, Физическое лицо)
Физические лица (Код, Фамилия, Имя, Отчество, Год рождения, Категория, Национальность)
Физическое лицо преподает (Код, Физическое лицо, Дисциплина)
Форма обучения (Код, Название)
Заявка (Код, Заявлено, Оплачено, Дата заявки, Физическое лицо, Дисциплина).
1.2.3 Физическое проектирование
Форма хранения данных. Все данные и другая информация СУБД хранятся на магнитных дисках в дисковых файлах. Файл данных представляет собой таблицу, каждая строка которой (запись) содержит некоторые сведения об описываемом объекте. Все записи базы данных имеют идентичную, заданную пользователем структуру и размеры.
Для привязки даталогической модели к среде хранения используется модель данных физического уровня (для краткости часто называемая физической моделью). Эта модель определяет используемые запоминающие устройства, способы физической организации данных в среде хранения. Модель физического уровня также строится с учетом возможности, представляемых СУБД. Описание физической структуры базы данных называется схемой хранения. Соответствующий этап проектирования базы данных называется физическим проектированием.
Данные в таблицах Access сохраняются в определенном формате, который называется типом данных. Типы данных могут быть классифицированы по четырем категориям: числовые (numeric), символьные (character), даты (date) и BLOB.
Числовые данные включают в себя все числа, начиная с целых вплоть до чисел двойной точности с плавающей точкой. Символьные данные содержат строки текста. Даты используются для хранения дат и времени.
Типы данных Access приведены в таблице 6.
Таблица 6. Типы данных Access
-
Тип
|
Размер
|
Диапазон
|
Описание
|
1
|
2
|
3
|
4
|
Текстовый
|
|
256 символов
|
Текст или числа не требующие проведения расчетов
|
MEMO
|
|
64000 символов
|
Предназначается для хранения больших текстовых данных
|
Байт
|
1 байт
|
от 0 до 255
|
|
Целое
|
2 байта
|
от -32 768 до 32 767
|
|
Длинное целое
|
4 байта
|
от -2 147 483 648 до
2 147 483 647
|
|
С плавающей
точкой (4 байт)
|
4 байта
|
от -3.402823Е38 до 3.402823Е38
|
|
С плавающей
точкой (8 байт)
|
8 байт
|
от -1.79769313486232Е308 до 1.79769313486232Е308
|
|
Код репликации
|
16 байт
|
|
Уникальный глобальный идентификатор (GUID)
|
Денежный
|
4 байта
|
от – 922337203685447.5808 до 922337203685447.5808
|
Денежные значения и числовые данные, используемые в математических расчетах, проводящихся с точностью до 15 в целой и до 4 знаков в дробной части
|
Счетчик
|
|
до 2 миллиардов
|
Уникалные последовательно возрастающие (на 1) или случайные числа, автоматически вводящиеся при добавлении каждой новой записи в таблицу
|
Логичес-кий
|
|
«Истина/Ложь»,«Да/Нет», -1/0
|
Логические значения, а так же поля, которые содержат одно из двух возможных значений.
|
Дата/
Время
|
|
|
Хранится в специальном фиксированном числовом формате. Дата является целой частью значения поля, а время его дробной частью
|
Поле объекта OLE
|
|
|
Объекты произвольного типа, связанный или внедренные в таблицу Access
| |
