Краткие сведения из теории моделирования данных
Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной или нескольких локальных моделей, которые относительно легко могут быть отображены в любую схему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы “сущность - связь” (ERD), нотация которых была впервые введена П.Ченом. Базовыми понятиями ERD являются:
Сущность (Entity) - реальный или воображаемый объект, имеющий существенное значение для рассматриваемой предметной области.
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь - это ассоциация между двумя сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.
Связь (отношение) между сущностями обладает свойством, именуемым мощность - количество экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя.
Например,
Наиболее типичной является связь “0, 1 или много” ( в теории реляционных баз данных - связь “1:М” или “один-ко-многим”).
Атрибут - любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с со множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
При проектировании данных рекомендуется создавать атомарные атрибуты, например, страна город - отдельные атрибуты при описании адреса.
Для обеспечения связи между сущностями используются понятия ключей :
Первичный ключ (главный ключ) - атрибут или группа атрибутов, однозначно идентифицирующая каждый экземпляр сущности. При выборе первичного ключа следует отдавать предпочтение наиболее простым ключам, имеющим числовой тип значений.
Первичный (главный) ключ должен обладать следующими свойствами:
Альтернативный ключ - заменитель главного ключа. Используется для организации поиска данных. Выбирается из числа ключей-кандидатов на роль главного ключа.
Внешний ключ - существует только для дочерней сущности и является ссылкой на значение ключа родительской сущности. При создании связей (отношений) между сущностями в дочернюю сущность передаются атрибуты, составляющие первичный ключ родительской сущности. Эти атрибуты и составляют внешний ключ.
1.2. Логическое моделирование данных. Методология IDEF1X
Под методологией понимают дисциплину проектирования:
Методология информационного моделирования IDEF1X основана на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме.
В методологии IDEF1X принята следующая терминология:
независимая сущность (независимая от идентификатора) - если каждый экземпляр может быть однозначно идентифицирован без определения его отношения с другими сущностями;
зависимая (зависимая от идентификатора) - если однозначная идентификация экземпляра сущности зависит от его отношения с другой сущностью (рис. П.1.1).
В методологии принята система простых графических символов для отражения понятий:
Рис. П.1.1 Обозначения для a) независимой и b) зависимой сущностей модели
Каждой сущности присваивается уникальное имя (существительное в единственном числе) и номер, разделенные косой чертой “/” и помещаемые над блоком.
Для описания связи указываются следующие элементы:
В IDEF1X могут быть выражены следующие мощности связей:
Тип связи
- если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей.Связь изображается линией, проводимой между сущностями, с точкой но конце линии у сущности-потомка (рис. П.2).
а) b)
Рис. П.2.2. Графическое изображение мощности связи
Идентифицирующая связь изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой сущностью. Сущность- родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью ( это определяется ее связями с другими сущностями).
Неидентифицирующая связь изображается пунктирной линией. Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный (главный, Primary Key) ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.
Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках (рис. П.1.3.).
Рис. П.1.3. Пример, показывающий неидентифицирующую связь
Как видно из примера на рис. П.1.3., главный ключ сущности 2
- “СЛУЖАЩИЙ” перешел в качестве FK в сущность 4 - “ПРОЕКТНОЕ-ЗАДАНИЕ” в область неключевых атрибутов.Пример идентифицирующей связи показан на рис. П.1.1.
В идентифицирующей связи первичный ключ сущности/1 переходит в качестве FK в сущность /3 и размещается в области главного ключа.
Ниже на рис. П.1.4. показан пример построения ER-модели по стандарту IDEF1X.
Рис.П.1.4. Пример построения ERD
Сущности — “клиент”, “модель”, “продавец”
- независимые (представляются прямоугольником), сущность “заказ” - зависимая (представляется прямоугольником со скругленными углами). Все связи между сущностями - идентифицирующие (показаны сплошной линией, главные ключи родительской сущности становятся внешними ключами дочерней сущности).В конрольном задании должны быть представлены описания концептуальной модели данных и диаграмма отношения сущностей предметной области. Отношения ER
- диаграммы должны быть представлены в нормализованной форме.На этапе проектирования физическая модель данных определяет сущности, атрибуты, связи, ограничения целостности в терминах конкретной СУБД. На этапе реализации физическая модель
- совокупность файлов определенного формата (.dbf для FoxPro). На этапе проектирования физической модели составляется описание реляционных таблиц, которые далее должны быть реализованы в среде конкретной СУБД (FoxPro for Windows, Access, Clarion ).Ниже, в табл.1 приведен пример описания физической модели данных на основе диаграммы отношения сущностей, представленной на рис. П.1.4.
Таблица 1
Описание таблиц базы данных
Customer (клиент)
- независимая|
№ п.п |
Идент.поля |
Наименов.поля |
Ключ |
Тип данных, длина поля |
Ограничения |
|
1 |
Key_custom |
Код клиента |
первичн |
символьный, 5 символов |
|
|
2 |
Name_custo |
Наименов. клиента |
|
символьный, 25 символов |
|
|
3 |
Adress |
Адрес |
|
символьный, 25 символов |
|
|
4 |
Tel |
Телефон |
|
символьный, 10 символов |
только цифры |
|
5 |
Fax |
Факс |
|
символьный, 10 символов |
только цифры |
|
.... |
...... |
....... |
|
|
|
Model (модель)
- независимая|
№ п.п |
Идент.поля |
Наименов.поля |
Ключ |
Тип данных, длина поля |
Ограничения |
|
1 |
Code_mod |
Код модели |
первичн |
числовой, 8 знаков |
целое, положит. число |
|
2 |
Name_mod |
Наименование модели |
|
символьный, 18 символов |
|
|
3 |
Volume |
Объем двигателя |
|
числовой, формат 5.2 |
|
|
... |
..... |
....... |
|
|
|
и т.д. в соответствии с диаграммой отношения сущностей.
По приведенной схеме должны быть описаны
все таблицы, предусмотренные логической моделью базы данных.1.4. Описание запросов к базе данных
Здесь следует привести перечень запросов и соответствующих им табличных и логических выражений. Например:
·
Список клиентов города N (далее должно следовать описание табличного выражения, позволяющего получить нужный список);·
Список продаж за период с____ по____ (далее - табличное выражение, необходимое для получения нужных сведений);·
Количество продаж определенной марки автомобиля за определенный период;·
и т.д.Следует составить не менее 4-х запросов к базе данных. Варианты спроектированных запросов следует согласовать с преподавателем (сложность, объем).
1.5. Описание отчетов, этикеток
Здесь следует привести формы отчетов, образцы отчетов, указанных в разделе проекта “Описание постановки задачи” и дать пояснения по структуре отчета (титул, колонтитулы, детали, группировка, итоги), составу полей отчета (поле базы данных, вычисляемое поле, константа, переменная).
В приложении, созданном на базе стандартного, должны быть использованы экраны, спроектированные и реализованные самостоятельно. В данном разделе проекта следует перечислить самостоятельно спроектированные экраны, кратко описать их структуру и назначение.
1.7. Описание набора макрокоманд
Для более быстрой и удобной работы в среде СУБД следует составить наборы полезных макрокоманд, научиться использовать стандартные наборы макрокоманд. В этом разделе проекта следует привести перечень созданных макрокоманд.
В приложении 2 приведены примеры выполнения выполнения проекта локальной базы данных.
Пример 1. Выполнен на основе работы студента группы
- Ф-261, Дидковского В.А., специальность - “Финансы и кредит”. В примере показаны результаты проектирования по всем разделам, кроме экранов, этикеток и макрокоманд.Пример 2. Выполнен на основе работы студента группы
- Марк-262, Боровкова Д.П., специальность - “Маркетинг”.В примере показаны все разделы проекта и пример реализации проекта в среде Access for Windows 95.
Рассмотрено и утверждено на заседании кафедры 8 июня 1998 г.
протокол № 10.