WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 | 2 || 4 | 5 |   ...   | 6 |

В качестве инфологической модели далее будет использоваться модель «сущность-связь».

• Даталогическая модель.

Модель описывает структуру данных и их взаимодействия в терминах, пригодных для представления в СУБД. В роли даталогической модели будет выступать реляционная модель данных.

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

Задача проектирования состоит в разработке инфологической модели данных и преобразовании ее в адекватную даталогическую.

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

Атрибуты – данные, описывающие свойства сущности. Примеры атрибутов: фамилия, цвет, стоимость, дата.

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

Следует различать тип сущности и конкретные ее экземпляры.

Тип сущности – признак принадлежности к некоторому классу (множеству) объектов (явлений). Тип сущности характеризуется множеством ее атрибутов.

Экземпляр сущности – конкретный объект, принадлежащий определенному классу объектов. Экземпляр сущности определяется значениями ее атрибутов.

Фактически, в базе данных хранятся только наборы значений атрибутов.

Каждый такой набор определяет один экземпляр сущности.

Пример 2.1.

Сущность – «персона» Экземпляр сущности «персона» Атрибуты: Значения атрибутов:

Фамилия Иванов Имя Иван Отчество Иванович Дата рождения 15.05.Номер паспорта 40 03 Номер телефона 123-45-67, 987-65-Обратим внимание, что атрибут «номер телефона» может иметь более одного значения.

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

В приведенном ранее примере атрибут «номер телефона» становится кандидатом на создание сущности «номер телефона».

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

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

Домен атрибута – множество значений, которые атрибут может принимать. Доменом может быть, например, множество допустимых значений даты, диапазон целых чисел или множество текстовых строк. Также это может быть множество цветов и оттенков или список компаний - поставщиков.

При реализации модели на языке конкретной СУБД домены приводятся в соответствие с имеющимися типами данных.

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

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

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

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

Связи между сущностями. После определения сущностей следует описать связи (взаимоотношения) между ними.

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

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

Виды связей:

• Один-к-одному • Один-ко-многим • Многие-ко-многим Вид связи определяется количеством экземпляров сущностей, участвующих в связи с каждой из сторон.

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

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

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

Пример связи «один-ко-многим» – связь между клиентом и его заказами.

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

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

«Один-ко-многим» - самый распространенный вид связи в реляционных базах данных.

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

Пример – связь между журналами и подписчиками. Подписчик может выписать несколько журналов и каждому наименованию журнала могут соответствовать много подписчиков.

Реляционная модель баз данных не позволяет реализовать связь «многиеко-многим». Эта проблема может быть решена введением дополнительной сущности (см. ниже).

ER-диаграммы. Наименование диаграмм происходит от английского «Entity-Relationship» («сущность-связь»).

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

Пример. 2.2. На рис. 2.1 представлена рассмотренная ранее сущность «Персона» в двух формах – классической и компактной. Символом «*» помечен атрибут, являющийся идентификатором сущности (иногда вместо использования звездочки, имя такого атрибута подчеркивают).

Персона Дата рождения *Номер *Номер Фамилия Персона Имя Паспорт Фамилия Отчество Дата рождения Паспорт Телефон Отчество Имя Телефон Рис. 2.1. Две формы представления сущности В классической форме представления ER-диаграмм связи между сущностями принято обозначать ромбом.

Пример 2.3. На рис. 2.2 изображена диаграмма, описывающая две сущности и связь между ними. Пометки «1» и «N» на концах указывают на то, что тип связи - «один ко многим».

1 N Клиент Заказ оформил Клиент *Номер Фамилия Имя N Отчество Заказ Кредитка *Номер Клиент Сумма Дата Рис. 2.2. Связи между сущностями В приведенном примере экземпляр клиента может существовать независимо от наличия заказов. Напротив, заказ обязательно должен быть связан с клиентом.

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

1 N Клиент Заказ оформил Рис. 2.3. Обозначение слабой сущности Преобразование связи «многие-ко-многим». Связь вида «многие-комногим» (рис. 2.4) нереализуема в реляционной модели данных.

N N Сущность 1 связь Сущность Рис. 2.4. Связь «многие-ко многим» Такую связь требуется преобразовать в две связи вида «один ко многим» введением некоторой вспомогательной сущности.

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

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

Составная сущность Уникальный идентификатор составной сущности образуется сочетанием идентификаторов связанных с ней сущностей.

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

Пример 2.4. Есть сущность «Товар», описывающая имеющиеся товары и сущность «Заказ», регистрирующая заказы, оформленные на эти товары.

Заказ Товар N N *Номер *Номер Клиент Наименование Дата Цена В каждый заказ может быть включено много видов товаров. Каждый вид товара может входить во многие заказы. Также необходимо где-то хранить информацию о количестве позиций каждого товара, входящего в заказ.

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

Решение проблемы – введение составной сущности «Состав заказа».

Заказ Состав заказа Товар 1 N N *Номер *Заказ *Номер Клиент *Товар Наименование Дата Количество Цена Каждый экземпляр сущности «Состав заказа» связан только с одним заказом и только с одним видом товара и содержит сведения о количестве единиц данного товара, входящих в данный заказ. Идентификатором экземпляра сущности «Состав заказа» является пара идентификаторов «Товар» и «Заказ».

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

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

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

2. Выявление сущностей и их атрибутов.

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

3. Выявление и анализ зависимостей (взаимосвязей) между различными сущностями или атрибутами.

На данном этапе может возникнуть необходимость изменения статуса некоторых объектов – преобразования сущности в атрибут или наоборот.

4. Определение способа идентификации экземпляров каждой сущности.

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

5. Определение доменов для выявленных атрибутов.

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

Пример 2.5. Воспользуемся приведенным алгоритмом построения модели.

1. В распоряжении разработчика имеются документы, представленные на рис. 2.6.

Преподаватели кафедры Назв. кафедры Код кафедры Телефон Табельный ФИО Дата Ученая Ученое номер рожд. степень звание Список студентов группы № Номер ФИО Дата Адрес … зачетки рожд.

2 Курс 3 Группа Препод. Предмет … Количество студентов_ … Рис. 2.6. Исходные документы 2. Анализ исходных документов позволяет выявить основные сущности и их атрибуты (рис. 2.7).

Кафедра Сотрудник Студент Группа НомерЗач НомерГр КодКаф ТабНомер Фамилия НазвКаф Фамилия Имя Телефон Имя Курс Отчество Отчество ДатаРожд ДатаРожд Группа Предмет Адрес Степень Предмет Звание Препод Название Рис. 2.7. Сущности и атрибуты 3. На рис.2.8. изображены выявленные между сущностями связи.

N 1 N Студент Группа Состоит в Слушает N Предмет Курс Читается в 1 N N Кафедра Сотрудник Состоит из Ведет Рис. 2.8. Связи между сущностями 4. На рис. 2.9 показаны сущности и их идентификаторы.

Кафедра Сотрудник Студент Группа *НомерЗач *НомерГр *КодКаф *ТабНомер Фамилия НазвКаф Фамилия Имя Телефон Имя Курс Отчество Отчество ДатаРожд ДатаРожд *Группа Предмет Адрес Степень *Предмет Звание *Препод *ID Название Рис. 2.9. Сущности и их идентификаторы 5. Анализ доменов позволил выявить новые потенциальные сущности – «УченаяСтепень» и «УченоеЗвание» (рис. 2.10).

Сотрудник УченаяСтепень *ID *ТабНомер Наименование Фамилия Имя Отчество ДатаРожд УченоеЗвание N Степень Звание *ID N Наименование Рис. 2.10. Новые сущности – значения доменов Модель, полученная в рассмотренном примере, разработана в учебных целях и не охватывает все возможные сущности и виды взаимодействия между кафедрами, преподавателями, студентами и курсами (аудитории, расписание, оборудование и т.п.).

2.2. Реляционная модель данных Начальные сведения о реляционной модели данных были даны в [1]. Здесь мы рассмотрим некоторые аспекты этой модели более детально.

Основной элемент реляционной модели – таблица (в реляционной терминологии синоним термина «таблица» - отношение). Таблица образуется столбцами (атрибутами) и строками (кортежами).

Таблицы могут быть базовыми или виртуальными. Базовые – таблицы, хранящиеся в БД постоянно. Множество базовых таблиц составляет схему БД.

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

Свойства столбцов:

• Имя столбца уникально в пределах одной таблицы.

Если при манипулировании с данными имена столбцов различных таблиц совпадают, к имени столбца добавляется префикс из имени таблицы и точки, например: Студент.Фамилия • Значения столбца принадлежат только одному домену.

При этом говорят, что таблицы однородны по столбцам.

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

Свойства строк:

• На пересечении столбца и строки находится только одно значение.

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

• Строки в таблице должны быть уникальными.

Если некоторые строки полностью совпадают, невозможно идентифицировать одну из них.

• Наличие первичного ключа.

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

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

Pages:     | 1 | 2 || 4 | 5 |   ...   | 6 |






© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.