Пользовательские представления

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

Любое пользовательское представление определяет требования к приложению базы данных в части хранимых в ней данных и транзакций, выполняемых над данными (т.е. оно определяет, какие действия и над какими данными должен выполнять тот или иной пользователь). Требования пользовательского представ­ления могут относиться только к данному представлению или частично совпа­дать с требованиями других представлений. На слайде (Слайд 6) схематически изображена предметная область приложения базы данных с несколькими пользовательскими представлениями (обозначены цифрами 1-6). Обратите внимание, что требования некоторых пользовательских представлений (1-2, а также 4-6) частично перекрываются (это показано штриховкой), а требования пользовательского представления 3 являются индивидуальными.

Сбор и анализ требований пользователей

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

- Изучение документации.

- Собеседование (интервьюирование) – выделяют не структурированные и структурированные интервью.

- Наблюдение за работой предприятия.

- Проведение исследований (поиск аналогичных решений).Проведение анкетирования (вопросы могут быть в свободной и фиксированной форме).

 

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

• Описание применяемых или вырабатываемых данных.

• Подробные сведения о способах применения или выработки данных.

• Все дополнительные требования к создаваемому приложению базы данных.

Эти требования описываются в документах, известных под общим названием спецификации требований к новому приложению базы данных.

Сбор и анализ требований является предварительным этапом концептуального проектирования базы данных. Объем работы зависит от сути проблемы и действующих бизнес-правил пред­приятия. Слишком тщательный анализ легко может привести к параличу сверх- анализа, а слишком поверхностный - к пустой трате средств на проведение работ по реализации решения, которое окажется ошибочным в результате неполной формулировки проблемы. Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впослед­ствии потребуется преобразовать и представить в виде более четко сформулиро­ванных требований. Эта цель достигается с помощью методов составления спе цификаций требований, к числу которых относятся, например, технология структурного анализа и проектирования (Structured Analysis and Design — SAD), диаграммы массивов данных (Data Flow Diagrams — DFD) и графики "вход-процесс-выход" (Hierarchical Input Process Output — HIPO).

Еще одним важным направлением деятельности, связанным с этим этапом, является определение того, как действовать в ситуации, если имеется несколько пользовательских представлений для рассматриваемого приложения базы дан­ных. Чтобы определить требования к приложению базы данных с несколькими пользовательскими представлениями, можно воспользоваться одним из следую­щих основных подходов.

• Централизованный подход.

• Метод интеграции представлений.

• Сочетание обоих подходов.

Централизованный подход предусматривает объединение требований к раз­личным пользовательским представлениям в единый набор требований, который в дальнейшем именуется общим представлением. На этапе проектирования базы данных создается глобальная модель данных, соответствующая общему представлению, иными словами, моде­лируемой области деятельности предприятия. Глобальная модель данных состо­ит из схем и документации, которая формально описывает требования пользова­телей базы данных. На слайде 9  показана схема применения централизованного подхода к управлению пользовательскими представлениями 1-3. Как правило, такой подход в основном применяется, если требования к каждому пользова­тельскому представлению в значительной степени перекрываются и приложение базы данных является не слишком сложным.

Метод интеграции представлении предусматривает оформление требований к каждому пользовательскому представлению в виде отдельного списка требова­ний. На этапе проектирования базы данных вначале создается модель данных для каждого пользовательского представления. Модель данных, соответствующая отдельному пользовательскому представлению, называется локальной моделью данных и состоит из схем и документации, которые формально описывают требования к конкретному пользовательскому представлению базы данных. Локальные модели данных затем объединяются на одном из последую­щих этапов проектирования базы данных для создания глобальной модели дан­ных, которая соответствует всем пользовательским требованиям к базе данных. На слайде 10  показана схема управления пользовательскими представлениями 1-3 с использованием метода интеграции представлений. Как правило, такой подход может рассматриваться как предпочтительный, если имеются существенные различия между пользовательскими представлениями и приложением базы данных, а приложение базы данных является достаточно сложным, чтобы имело смысл разделить работу по его созданию на отдельные направления.

Критерии оценки модели

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

Проверка концептуальной модели на адекватность (слайд 12)

- Проверка модели на отсутствие избыточности

- Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям

- Обсуждение локальных концептуальных моделей с конечными пользователями.

Лекция 9 (DB_l09)

Модель «сущность-связь». Основные понятия: Сущность, Свойства, Связи. Представление сущностей, свойств, связей

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

Наиболее распространенным средством моделирования предметной области систем, ориентированных на обработку фактографической информации, является модель «сущность-связь» (Entity-Relationship Model - ERМ), впервые предложенная Питером Пин-Шэн Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, но, по существу, реализует объектный подход к моделированию предметной области.

Модель “сущность-связь” положена в основу значительного количества коммерческих CASE-продуктов, поддерживающих полный цикл разработки систем баз данных или отдельные его стадии. При этом многие из них не только поддерживают стадию концептуального проектирования предметной области разрабатываемой системы, но и позволяют осуществить на основе построенной их средствами модели стадию логического проектирования путем автоматической генерации концептуальной схемы базы данных для выбранной СУБД, например, схемы базы данных для какого-либо SQL-сервера или объектной СУБД.

Моделирование предметной области в этом случае базируется на использовании графических диаграмм, включающих сравнительно небольшое число компонентов (слайд 2) и, самое важное – технологию построения таких диаграмм.

Семантическую основу ER-модели составляют следующие предположения:

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

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

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

- систематизация представления, основанная на классах, в общем случае предполагает иерархическую зависимость типов: сущность типа А является подтипом сущности B, если каждый экземпляр типа А является экземпляром сущности типа B;

- взаимосвязи объектов могут быть представлены как связи – сущности[5], которые служат для фиксирования (представления) взаимозависимости двух или нескольких сущностей.

 

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

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

На слайде 3 приведенный пример представления сущности, который не является полным и не претендует на точное соответствие какой либо версии построения ER-диаграмм.

 

ER-модель, как описание предметной области, должна определить объекты и взаимосвязи между ними, т.е. установить связи следующих двух типов:

1. связи между объектами и наборами характеристических свойств и таким образом определить сами объекты;

2. связи между объектами, задающие характер и функциональную природу их взаимозависимости.

 

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

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

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

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

 

Свойства (слайд 4)

  Природа свойства, как характер связи свойства с сущностью (объектом), может быть различной. Рассмотрим основные виды свойств.

Свойство может быть множественным или единичным – т.е. атрибут, задающий свойство, может одновременно иметь несколько значений или, соответственно, только одно. Например, сотрудник может иметь несколько специальностей, но единственное значение «Таб. номер».

Свойство может быть простым  (не подлежащих дальнейшему делению с точки зрения прикладных задач) или составным – если его значение составляется из значений простых свойств. Например, свойство «Год рождения» является простым, а свойство «Адрес» - составным, т.к. включает значения простых свойств «Город», «Улица», «Дом».

В некоторых случаях полезно различать базовые и производные свойства. Например, «Поставщик» может иметь свойство «Общее количество поставляемых деталей», которое вычисляется суммированием количества деталей, поставляемых им по проекту.

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

Значения свойств могут быть постоянными - статическими, или динамическими, т.е. меняться со временем. Например, свойство «Таб. номер» является статическим, а «Адрес» - динамическим. Свойство может быть неопределенным, если оно является динамическим, но его текущее значение еще не задано.

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

 

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

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

Сущности, объединяемые связью, называются участниками. Степень связи определяется количеством участников связи[6].

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

Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (1:М), «многие к одному» (М:1), «многие ко многим» (М:М)[7] (Слайды 5, 6, 7).

 

Следует отметить, что инструмент связей - это средство представления сложных объектов, каждый из которых может рассматриваться как множество некоторым образом взаимосвязанных простых объектов. Деление на простые и сложные объекты, также как и характер взаимосвязи, является условным и определяется особенностям анализа предметной области, т.е. в конце концов – характером использования данных о предметах в решаемых прикладных задачах. При этом с точки зрения, например, конструктора, ДЕТАЛЬ является сложным объектом, а с точки зрения поставщика – простым.

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

Отношение «часть-целое» используются для представления составных объектов. Например, МАШИНЫ состоят из УЗЛОВ, УЗЛЫ состоят из ДЕТАЛЕЙ. Здесь возможны как отношения  «один ко многим», так и «многие ко многим».

Отношение «род-вид» - для представления обобщенных объектов. Например, СОТРУДНИКИ подразделяются по профессии на КОНСТРУКТОРОВ, ПРОГРАММИСТОВ, РАБОЧИХ; ПРОГРАММИСТЫ – на ПРИКЛАДНЫХ ПРОГРАММИСТОВ и СИСТЕМНЫХ ПРОГРАММИСТОВ. Иерархические отношения, и, в частности – «родо-видовые», обычно используются как основа классификации объектов по наборам характеристических признаков. Причем «видовые» объекты наследуют свойства «родовых».

Другой широко используемой разновидностью взаимосвязи является агрегирование – объединение простых объектов в сложный по принципу их принадлежности агрегату или их совместного участия в некотором процессе. Агрегирование, рассматриваемое здесь как более общий случай иерархических отношений, объединяет объекты разной природы с единственным общим свойством «совместное участие». Агрегированные объекты именуются обычно отглагольными существительными, например, «Состав»: ПОДРАЗДЕЛЕНИЕ состоит из СОТРУДНИКОВ; «Поставка»: ПОСТАВЩИК поставляет ДЕТАЛИ.

 

Супертипы и подтипы. Сущность может быть расщеплена на два или более взаимно исключающих подтипов, каждый из которых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. В принципе выделение подтипов может продолжаться на более низких уровнях, но в большинстве случаев оказывается достаточно двух-трех уровней.

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

Подтип наследует свойства и связи супертипа. Например, тип сущности ПРОГРАММИСТ является подтипом сущности СОТРУДНИК. Программисты обладают всеми свойствами сотрудников и участвуют во всех связях, однако обратные утверждения неверны.

Тип сущности, его подтипы, подтипы этих подтипов и т.д. образуют иерархию типов сущности, пример которой приведен на  Слайде 8.  

 

ER- диаграмма

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

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

 

Сущности. Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника, содержащего имя сущности. В качестве имени обычно используются существительные (или обороты существительного) в единственном числе. Для отражения сущностей слабых типов используются прямоугольники, стороны которых рисуются двойными линиями. Например, в представленной на слайде 9  ER-диаграмме ПОДЧИНЕННЫЙ – сущность слабого типа.

 

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

Имена ключевых свойств подчеркиваются. Например, свойство «Таб.номер» сущности СОТРУДНИК.

Контур эллипса рисуется двойной линией, если свойство многозначное. Например, свойство «специальность» сущности СОТРУДНИК.

Контур эллипса рисуется штриховой линией, если свойство производное. Например, свойство «кол-во» сущности ПОСТАВЩИК.

Эллипс соединяется пунктирной линией, если свойство условное. Например, свойство «Ин. язык» сущности СОТРУДНИК.

Если свойство составное, то составляющие его свойства отображаются другими эллипсами, соединенными с эллипсом составного. Например, свойство «Адрес» сущности СОТРУДНИК состоит из простых свойств «Город», «Улица», «Дом».

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

Стороны ромба рисуют двойными линиями, если это связь сущности слабого типа с сущностью от которой она зависит. Например, связь «Подчинение», связывающая сущность слабого типа ПОДЧИНЕННЫЙ с сущностью СОТРУДНИК, от которой она зависит.

Участники связи соединены со связью линиями. Двойная линия обозначает полное участие сущности в связи с данной стороны. Например, связь «Подчинение», со стороны сущности ПОДЧИНЕННЫЙ.

Связь может быть модифицирована указанием роли. Например, для рекурсивной связи «Состав», указаны роли: «Деталь состоит из …» и «Деталь входит в состав …».

Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать многие сотрудники.

 

Пример нормализованной формы ER-диаграммы приведен на слайде 10.

 

Одна из разновидностей модели «сущность-связь» используется в нотации IDEF1Х, входящем в семейство стандартов IDEF.

Графический язык модели и пример диаграммы представлены на слайде 11.

Необязательные связи между сущностями Отдел и Сотрудник, Сотрудник и Подчиненный имеют мощность «один ко многим» (конец связи «многие» обозначен жирной точкой), а обязательная связь между сущностями Сотрудник и Проект имеет мощность «многие ко многим».

Графические элементы основных нотаций модели «сущность-связь» представлены на слайде 12.

 

 

Лекция 10 (DB _ l 10. ppt).