Лекция 7. инфологическое моделирование

Введение искусственных идентификаторов

При отображении объекта в файл базы данных идентификатор объекта будет являться полем этого файла, причем в большинстве случаев — ключевым полем, т.е. полем, однозначно идентифицирующим запись. Однако в некоторых случаях появляется необходимость введения искусственных идентификаторов, или, как их еще называют, кодов. Такими случаями являются следующие.

1. В предметной области может наблюдаться синонимия, т.е. может случиться, что естественный идентификатор объекта не обладает свойством уникальности. Например, среди сотрудников предприятия могут быть однофамильцы. В этом случае для обеспечения однозначной идентификации объектов предметной области в информационной системе целесообразно использовать искусственные коды.

2. Если объект участвует во многих связях/процессах, то для их отображения создается несколько файлов/таблиц, в каждом из которых повторяется идентификатор объекта. Для того чтобы не использовать во всех файлах длинный естественный идентификатор объекта, можно ввести и использовать более короткий код. Например, вместо длинных наименований продукции обычно используются их кодовые обозначения. Это не только сэкономит память, но и сократит трудоемкость ввода информации (хотя последнего можно достичь и другим путем).

3. Если естественный идентификатор может изменяться со временем (например, фамилия), то это может вызвать много проблем, если наряду с таким динамическим идентификатором не использовать статический искусственный идентификатор.

Когда присваиваются идентификаторы каким-либо объектам, то желательно, чтобы эти идентификаторы были постоянными. Например, в учебных заведениях всегда каким-либо образом обозначаются учебные группы. Для этого можно, например, использовать номер курса, на котором в настоящее время учится данная группа, и какие-то другие символы (подобно тому, как обозначаются классы в школе). Но в этом случае идентификатор группы будет каждый год меняться. А можно для обозначения группы использовать, например, две последние цифры года поступления. В этом случае идентификатор группы будет постоянным. Использование постоянных идентификаторов снимает множество проблем при функционировании информационной системы.

Исходные данные для даталогического проектирования

Любая СУБД оперирует с допустимыми для нее логическими единицами данных, а также допускает использование определенных правил композиции логических структур более высокого уровня из составляющих информационных единиц более низкого уровня. Кроме того, многие СУБД накладывают количественные и иные ограничения на структуру базы данных. Поэтому прежде чем приступить к построению даталогической модели, необходимо детально изучить особенности СУБД, определить факторы, влияющие на выбор проектного решения, ознакомиться с существующими методиками проектирования, а также провести анализ имеющихся средств автоматизации проектирования, возможности и целесообразности их использования.


Хотя даталогическое проектирование является проектированием логической структуры базы данных, на него оказывают влияние возможности физической организации данных, предоставляемые конкретной СУБД. Поэтому знание особенностей физической организации данных является полезным при проектировании логической структуры.

Логическая структура базы данных, а также сама заполненная данными база данных являются отображением реальной предметной области. Поэтому на выбор проектных решений самое непосредственное влияние оказывает специфика отображаемой предметной области, отраженная в инфологической модели.

1.1. Даталогическое проектирование

Инфологическая модель является исходной для построения даталогической модели БД и служит промежуточной моделью для специалистов предметной области (для которой создается банк данных (БнД)) и администратора БД в процессе проектирования и разработки конкретной БД.Поддаталогической понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физической организации. При этом даталогическаямодель разрабатывается с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфологической модели.^

1.2. Описание датологической модели..

Nп.п. Наименование реквизита Иденти-фикатор Тип Длина Формат изобра-жения Ограничения и комментарий
  1. допускаются ли дубликатные значения индекса (Dup);
  2. допускаются ли нулевые значения ключа (Null);
  3. следует ли различать символы верхнего и нижнего регистров в индексных полях строкового типа (Case);
  4. порядок упорядочения значений индекса (по возрастанию или убыванию) (Desc);
  5. допускается ли модификация значений индексных полей (Mod);
Nп.п. Наименование реквизита Идентификатор Тип Длина Формат изображения Ограничения и комментарий
1 Таб.номер TabNo Integer 4 InputLine Уникальный
2 Фамилия И О FIO Char 25 InputLine
3 Шифр категория Kateg Byte 1 DDLB (Drop Down List Box) Категория работника
4 Оклад Oklad Decimal 10,2 InputLine Оклад (грн)
  1. ^ ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ

2.1. Выбор задания^ 2.2. Построение даталогической модели.

  • провести соответствие ключей для каждой таблицы 1.1-1.3 из лабораторной работы №1,
  • заполнить для каждой таблицы БД форму, согласно табл. 4.1.

^ 3. СОДЕРЖАНИЕ ОТЧЕТА

  1. Название и цель работы .
  2. Даталогическая модель БД (табл. 4.1.).
  3. Выводы

4. КОНТРОЛЬНЫЕ ВОПРОСЫ ПРИЛОЖЕНИЕ

1.1. Описание предметной области

Программа Прокат предназначена для автоматизации пункта проката или продажи видеокассет или любых других товаров. Она ведет учет выдаваемых товаров по клиентам, платежей и взаиморасчетов с клиентами и формирует все необходимые документы и отчеты. В программе предусмотрена возможность учета заказов, продажи, различные схемы обслуживания клиентов. Для ускорения обслуживания, работа может вестись с применением технологий штрихового кодирования и членских карточек. Программа имеет развитую систему разделения доступа сотрудников к различным функциям и отчетам. Имеется возможность разрабатывать и печатать этикетки товаров и карточки постоянных клиентов (в том числе и с штрихкодом).

Программа работает в ОС Windows 95/98/ME, Windows 2000/2003/NT/XP. Минимальные требования: компьютер, на котором способна работать какая-нибудь Windows, 4 Мбайта места на жестком диске плюс размер данных. Разрешение экрана монитора должно быть не менее чем 800×600.

Программа «Прокат » работает на одном или нескольких компьютерах операторов пункта проката и выполняет следующие основные функции:

· Регистрация клиентов, формирование и печать персональных карточек клиентов

· Ввод товаров, печать этикеток товаров. Имеются средства для разработки дизайна карточек клиентов и этикеток товаров

· Автоматическое определение клиентов и товаров по их штрих-кодам. Возможен быстрый поиск товаров по названию, группе (жанру), ценовой категории, стране, режиссеру, студии, актеру, году выпуска…

· Выдача и возврат из проката, резервирование (заказ) и продажа товаров с регистрацией всех операций в журнале учета


· Гибкая система настройки различных схем обслуживания клиентов в зависимости от их Категории: залоговая, абонементная, предоплата, VIP…

· Прием оплаты от клиентов, печать чеков, приходных и расходных ордеров, актов, счетов-фактур, договора с клиентом и т.п.

· Учет взаиморасчетов с каждым клиентом за всю историю, возможность применения различных схем взаиморасчетов

· Всевозможные отчеты по товарам: каталоги, по популярности, справки о наличии…

· Экспорт данных в Excel и формирование там документа «Учет доходов предпринимателя»

· Различные отчеты по клиентам, справка о должниках, справка о клиенте

· Отчеты по оборотам за день, за произвольный период

· Возможность блокировки, разблокировки, и замены карточки клиента. Занесение клиента в «черный список»

· Возможность работы в любой валюте (рубли, гривны, USD, EUR и т.п.)

· Возможность автоматической печати чеков на кассовом аппарате АМС-100Ф

· Разграничение доступа к функциям системы для сотрудников пункта проката


· Простой и понятный, настраиваемый интерфейс пользователя. Поддержка нескольких языков интерфейса (в настоящее время имеется русский и английский интерфейс)

· Подробная справочная система, техническая поддержка пользователей

Система «Прокат » полностью автоматизирует всю деятельность пункта проката. Программа может работать в сети связанных между собой компьютеров, принтеров, принтеров этикеток и карточек, сканеров штрих кодов.

Система «Прокат » функционирует в соответствии с общепризнанными технологиями работы пунктов проката и позволяет оптимизировать все процессы, связанные с обслуживанием клиентов. Давайте рассмотрим эту технологию подробнее.

Основные понятия

  • Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.
  • Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

Требования, предъявляемые к инфологической модели

  • Адекватное, отображение предметной области
  • Недопущение неоднозначной трактовки модели
  • Четкое определение моделируемой предметной области (конечность модели)
  • Легкая расширяемость, обеспечивающая ввод новых данных без изменения ранее определенных, то же относят и к удалению данных
  • Возможность композиции и декомпозиции модели в связи с большой размерностью реальных инфологических моделей
  • Легкое восприятие различными категориями пользователей; желательно, чтобы инфологическую модель строил (или хотя бы участвовал в ее создании) специалист, работающий в данной предметной области, а не только проектировщик систем машинной обработки данных
  • Применимость языка спецификаций модели как при ручном, так и при автоматизированном проектировании информационных систем

Определение состава базы данных

При переходе от инфологической модели к даталогической следует иметь в виду, что инфологическая модель включает в себя всю информацию о предметной области, необходимую и достаточную для проектирования БД. Это не означает, что все сущности, зафиксированные в ИЛМ, должны в явном виде отражаться в даталогической модели. Прежде чем строить даталогическую модель, необходимо решить, какая информация будет храниться в базе данных. Например, в инфологической модели должны быть отражены вычисляемые показатели, но вовсе не обязательно, что они должны храниться в базе данных.

Существуют разные подходы к определению состава показателей, которые должны храниться в базе данных. Согласно одному из них в БД должны храниться только исходные показатели, все производные показатели должны быть получены расчетным путем в момент реализации запроса (этот подход иногда называют принципом синтезирования, имея в виду возможность синтезировать требуемые показатели из хранимых в информационной базе данных).

Такой подход имеет очевидные достоинства:

простота и однозначность в принятии решения «что хранить»;

отсутствие неявного дублирования информации со всеми вытекающими из этого последствиями (меньше объем памяти, чем при хранении как исходных, так и производных показателей; проще проблемы контроля целостности данных);

потенциальная возможность получить любой расчетный показатель, а не только те, которые хранятся в БД.

При принятии решения о хранении расчетных показателей должны учитываться разные факторы.

Рассмотрим некоторую гипотетическую предметную область, представляющую собой учебное заведение. Учащимся этого заведения начисляется стипендия. Существует четкий алгоритм начисления стипендии. Предположим, что он выглядит следующим образом.

Стипендия начисляется только тем, кто успешно сдал все экзамены в сессию (т.е. сдал в срок и не получал неудовлетворительных оценок), а также учащимся, имеющим детей.

Известен размер обычной стипендии.

Тем, кто не имеет удовлетворительных оценок, назначается стипендия на 25% выше, чем обычная.

Тем, кто имеет только отличные оценки, стипендия увеличивается на 50% от размера обычной стипендии.

Предположим также, что размер стипендии не может изменяться в течение семестра. Таким образом, размер стипендии является вычисляемым показателем и может не храниться в базе данных, а каждый раз определяться расчетным путем. Однако в рассматриваемой ситуации его все-таки лучше хранить в БД по следующим основным причинам:

полученная величина многократно используется в дальнейшем;

алгоритм определения размера стипендии имеет достаточно сложную логику, и для выполнения расчета требуется просмотреть несколько файлов (некоторые из них являются большими по объему, что также замедляет процесс обработки);

размер стипендии не должен изменяться в течение семестра. Кроме того, имея реальный файл «Начисленная стипендия», легче контролировать его полноту и достоверность.

Предположим также, что к БД достаточно часто обращаются с запросом о среднем балле какого-либо студента или среднем балле по той или иной дисциплине и т.п.

При изменении любой оценки или получении новой средний балл меняется, и если вы вдруг решите хранить и среднюю величину, и исходные оценки, то обеспечение их соответствия может стать проблемой. При правильной организации файлов вычисление средней величины во время исполнения запроса не представляет проблемы ни с точки зрения времени обработки, ни в аспекте задания запроса. Поэтому хранить средний балл не следует.

2.1. Модель «сущность-связь»

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель «сущность-связь» и т.д. Наиболее популярной из них оказалась модель «сущность-связь» или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).

Инфологическая модель применяется после словесного описания предметной области.

Между сущностями могут быть установлены связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности


Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).

Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.

Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.

Связь «многие-ко-многим (М:М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.

Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной – если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.

Проведем инфологическое проектирование базы данных технологического процесса. Инфологическая модель применяется после словесного описания предметной области. На основании анализа предметной области выделим следующие сущности модели «сущность-связь» («EntityRelationship» — ER-модели): «Рубрикатор видов деятельности», «Предприятия и организации», и изобразим их в виде графических обозначений (прямоугольник, в верхней части которого записано имя сущности, а ниже перечисляются атрибуты, причем ключевые атрибуты помечаются подчеркиванием). Они приведены на рис. 1-2.

Справочник клиентов
Код клиента
Фамилия, ИО
Адрес
Телефон
Категория
Примечания

рис.1. «Справочник клиентов»

Видеотека
Код кассеты
Наименование
Категория
Стоимость

рис.2. «Видеотека»

Заказы
Код заказа
Дата
Код клиента
Код кассеты
Сумма
Дата возврата

рис.3. «Заказы»

Сотрудники
Код сотрудника
Фамилия ИО
Табельный номер

Рис.4. «Сотрудники»


С этим читают