ER -диаграммы
Общим способом представления логической модели БД является построение ER-диаграмм (Entity-Relationship - сущность-связь). В этой модели сущность определяется как дискретный объект, для которого сохраняются элементы данных, а связь описывает отношение между двумя объектами.
В примере менеджера турфирмы имеются 5 основных объектов:
Туристы
Путевки
Отношения между этими объектами могут быть определены простыми терминами:
Каждый турист может купить одну или несколько (много) путевок.
Каждой путевке соответствует ее оплата (оплат может быть и несколько, если путевка, например, продана в кредит).
Каждый тур может иметь несколько сезонов.
Путевка продается на один сезон одного тура.
Эти объекты и отношения могут быть представлены ER- диаграммой, как показано на рис 2.
Рис. 2. ER-диаграмма для приложения БД менеджера турфирмы
Объекты, атрибуты и ключи
Далее модель развивается путем определения атрибутов для каждого объекта. Атрибуты объекта - это элементы данных, относящиеся к определенному объекту, которые должны сохраняться. Анализируем составленный словарь данных, выделяем в нем объекты и их атрибуты, расширяем словарь при необходимости. Атрибуты для каждого объекта в рассматриваемом примере представлены в таблице 2.
Таблица 2. Объекты и атрибуты БД
|
Объект |
Туристы |
Путевки |
Туры |
Сезоны |
Оплаты |
|
Название |
Дата начала |
Дата оплаты |
|||
|
Дата конца |
|||||
|
Отчество |
Информация |
||||
|
Атрибуты |
|||||
Следует обратить внимание, что несколько элементов отсутствуют. Опущена регистрационная информация, упомянутая в функциональной спецификации. Как ее учесть, вы подумаете самостоятельно и доработаете предложенный пример. Но более важно то, что пока отсутствуют атрибуты, необходимые для связи объектов друг с другом. Эти элементы данных в ER-модели не представляются, так как не являются, собственно, «натуральными» атрибутами объектов. Они обрабатываются по-другому и будут учтены в реляционной модели данных.
Реляционная модель характеризуется использованием ключей и отношений. Существует отличие в контексте реляционной базы данных терминов relation (отношение) и relationship (схема данных). Отношение рассматривается как неупорядоченная, двумерная таблица с несвязанными строками. Схема данных формируется между отношениями (таблицами) через общие атрибуты, которые являются ключами.
Существует несколько типов ключей, и они иногда отличаются только с точки зрения их взаимосвязи с другими атрибутами и отношениями. Первичный ключ уникально идентифицирует строку в отношении (таблице), и каждое отношение может иметь только один первичный ключ, даже если больше чем один атрибут является уникальным. В некоторых случаях требуется более одного атрибута для идентификации строк в отношении. Совокупность этих атрибутов называется составным ключом. В других случаях первичный ключ должен быть специально создан (сгенерирован). Например, в отношение «Туристы» имеет смысл добавить уникальный идентификатор туриста (код туриста) в виде первичного ключа этого отношения для организации связей с другими отношениями БД.
Другой тип ключа, называемый внешним ключом, существует только в терминах схемы данных между двумя отношениями. Внешний ключ в отношении - это атрибут, который является первичным ключом (или частью первичного ключа) в другом отношении. Это - распределенный атрибут, который формирует схему данных между двумя отношениями в БД.
Для проектируемой БД расширим атрибуты объектов кодовыми полями в качестве первичных ключей и используем эти коды в отношениях БД для ссылки на объекты БД следующим образом (табл. 3).
Построенную схему БД еще рано считать законченной, так как требуется ее нормализация. Процесс, известный как нормализация реляционной БД, используется для группировки атрибутов специальными способами, чтобы минимизировать избыточность и функциональную зависимость.
Таблица 3. Объекты и атрибуты БД с расширенными кодовыми полями
|
Объект |
Туристы |
Путевки |
Туры |
Сезоны |
Оплаты |
|
Атрибуты |
Код туриста |
Код путевки |
Код сезона |
Код оплаты |
|
|
Код туриста |
Название |
Дата начала |
Дата оплаты |
||
|
Код сезона |
Дата конца |
||||
|
Отчество |
Информация |
Код путевки |
|||
Нормализация
Функциональные зависимости проявляются, когда значение одного атрибута может быть определено из значения другого атрибута. Атрибут, который может быть определен, называется функционально зависимым от атрибута, который является детерминантом. Следовательно, по определению, все неключевые (без ключа) атрибуты будут функционально зависеть от первичного ключа в каждом отношении (так как первичный ключ уникально определяет каждую строку). Когда один атрибут отношения уникально не определяет другой атрибут, но ограничивает его набором предопределенных значений, это называется многозначной зависимостью. Частичная зависимость имеет место, когда атрибут отношения функционально зависит от одного атрибута составного ключа. Транзитивные зависимости наблюдаются, когда неключевой атрибут функционально зависит от одного или нескольких других неключевых атрибутов в отношении.
Процесс нормализации состоит в пошаговом построении БД в нормальной форме (НФ).
1. Первая нормальная форма (1НФ) очень проста. Все таблицы БД должны удовлетворять единственному требованию - каждая ячейка в таблицах должна содержать атомарное значение, другими словами, хранимое значение в рамках предметной области приложения БД не должно иметь внутренней структуры, элементы которой могут потребоваться приложению.
2. Вторая нормальная форма (2НФ) создается тогда, когда удалены все частичные зависимости из отношений БД. Если в отношениях не имеется никаких составных ключей, то этот уровень нормализации легко достигается.
3. Третья нормальная форма (3НФ) БД требует удаления всех транзитивных зависимостей.
4. Четвертая нормальная форма (4НФ) создается при удалении всех многозначных зависимостей.
БД нашего примера находится в 1НФ, так как все поля таблиц БД атомарные по своему содержанию. Наша БД также находится и во 2НФ, так как мы искусственно ввели в каждую таблицу уникальные коды для каждого объекта (Код Туриста, Код Путевки и т. д.), за счет чего и добились 2НФ для каждой из таблиц БД и всей базы данных в целом. Осталось разобраться с третьей и четвертой нормальными формами.
Обратите внимание, что они существуют только относительно различных видов зависимостей атрибутов БД. Есть зависимости - нужно стоить НФ БД, нет зависимостей - БД и так находится в НФ. Но последний вариант практически не встречается в реальных приложениях.
Итак, какие же транзитивные и многозначные зависимости присутствуют в нашем примере БД менеджера турфирмы?
Давайте проанализируем отношение «Туристы». Рассмотрим зависимости между атрибутами «Код туриста», «Фамилия», «Имя», «Отчество» и «Паспорт» (рис. 3). Каждый турист, представленный в отношении сочетанием «Фамилия- Имя-Отчество», имеет на время поездки только один паспорт, при этом полные тезки должны иметь разные номера паспортов. Поэтому атрибуты «Фамилия- Имя-Отчество» и «Паспорт» образуют в отношении туристы составной ключ.
Рис. 3. Пример транзитивной зависимости
Как видно из рисунка, атрибут «Паспорт» транзитивно зависит от ключа «Код туриста». Поэтому, чтобы исключить данную транзитивную зависимость, разобьем составной ключ отношения и само отношение на 2 по связям «один-к-одному». В первое отношение, оставим ему имя «Туристы», включаются атрибуты «Код туриста» и «Фамилия», «Имя», «Отчество». Второе отношение, назовем его «Информация о туристах», образуют атрибуты «Код туриста» и все оставшиеся атрибуты отношения «Туристы»: «Паспорт», «Телефон», «Город», «Страна», «Индекс». Эти два новых отношения уже не имеют транзитивной зависимости и находятся в 3НФ.
Многозначные зависимости в нашей упрощенной БД отсутствуют. Для примера предположим, что для каждого туриста должны храниться несколько контактных телефонов (домашний, рабочий, сотовый и пр., что весьма характерно на практике), а не один, как в примере. Получаем многозначную зависимость ключа - «Код туриста» и атрибутов «Тип телефона» и «Телефон», в этой ситуации ключ перестает быть ключом. Что делать? Проблема решается также путем разбиения схемы отношения на 2 новые схемы. Одна из них должна представлять информацию о телефонах (отношение «Телефоны»), а вторая о туристах (отношение «Туристы»), которые связываются по полю «Код туриста». «Код туриста» в отношении «Туристы» будет первичным ключом, а в отношении «Телефоны» - внешним.
На рисунке 1 представлена логическая модель базы данных студенческого общежития.
Рисунок 1 – логическая модель
Логическая (даталогическая) модель представляет собой модель базы данных, которая не привязана к конкретной СУБД. В ней выделяют основные объекты БД и определяют связи между этими объектами. Иногда определятся типы данных отдельных объектов. Данная модель построена методом Сущность-связь (Entity Relationship).
2.2 Сущности
Данная БД содержит 16 сущностей. Разберем каждую из них и связи между ними.
Сущность Форм_об содержит два атрибута: Ном_фо – порядковый номер формы обучения, и Форм_об – форма обучения, первый из которых является ключевым. В этой сущности содержатся возможные варианты форм обучения (бюджетная и контрактная).
Сущность Статус также содержит два атрибута: Ном_ст – порядковый номер статуса (ключевой атрибут), и Статус – наименование статуса. Статус может принимать два значения: студент и аспирант.
Сущность Факультет содержит информацию о факультетах. Первый атрибут (ключевой) Ном_фак – порядковый номер факультета, второй атрибут Факультет – сокращенное наименование факультета.
Сущность Специальность содержит информацию о специальностях ВУЗа. В качестве атрибутов – порядковый номер и цифровое обозначение специальности.
Сущность Комната содержит номера комнат и количество свободных в них мест. Так как по условию не должно быть незаселенных комнат и в комнате всего 3 места, нужно будет выставить соответствующее ограничение на ввод данных.
Сущность Тарифы содержит порядковый номер тарифа, определяющие стоимость критерии – номер статуса и номер формы обучения, и саму стоимость тарифа.
Сущность Группа содержит номер группы, определяющие критерии – номер факультета и номер специальности, а также курс.
В сущности Личн_дан находится информация о личных данных студента. Его номер студенческого билета, фамилия, имя, отчество, номер и серия паспорта, дата рождения, место рождения, место прописки и место жительства.
Сущность Студент содержит номер студенческого билета, номер тарифа оплаты за проживание в общежитии, дату поступления в ВУЗ и дату окончания ВУЗа.
Сущность Изменения содержит информацию об изменениях, которые произошли во время учебы. В качестве атрибутов она содержит номер изменения, наименование факультета, номер специальности, номер курса, номер группы, номер формы обучения и номер статуса.
Сущность Студ_измен служит для связи сущностей Студент и Изменения . Она содержит номер изменения, номер студенческого билета и дату, когда произошло изменение.
Сущность Студ_груп также является связующей сущностей Студент и Группа . В ней содержатся номер студенческого билета, номер группы и информация об отчислении и восстановлении студентов.
Еще одна связующая сущность – Студ_комн . Предназначена для хранения номера переселения студентов, номера студенческого билета, номера комнаты и дат заселения и выселения.
Архив – сущность для хранения веселенных студентов. Содержит номер записи, номер студенческого билета и дату выселения.
В сущности Неуплата содержится порядковый номер неуплаты, номер студенческого билета студента, который не заплатил за проживание, и неоплаченные им месяц и год.
В сущности Родители содержится информация о родителях студента, такая как ФИО отца и матери и состояние их брака, что может потребоваться для выплат дополнительных пособий студенту.
- ознакомиться с технологией построения логической модели в ERWin,
- изучить методы определения ключевых атрибутов сущностей,
- освоить метод проверки адекватности логической модели,
- изучить типы связей между сущностями.
Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.
ERD-диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации.
ERD-диаграммы можно подразделить на отдельные куски, соответствующие отдельным задачам, решаемым проектируемой системой. Это позволяет рассматривать систему с точки зрения функциональных возможностей, делая процесс проектирования управляемым.
ERD-диаграммы
Как известно основным компонентом реляционных БД является таблица. Таблица используется для структуризации и хранения информации. В реляционных БД каждая ячейка таблицы содержит одно значение. Кроме того, внутри одной БД существуют взаимосвязи между таблицами, каждая из которых задает совместное пользование данными таблицы.
ERD-диаграмма графически представляет структуру данных проектируемой информационной системы. Сущности отображаются при помощи прямоугольников, содержащих имя. Имена принято выражать существительными в единственном числе, взаимосвязи - при помощи линий, соединяющих отдельные сущности. Взаимосвязь показывает, что данные одной сущности ссылаются или связаны с данными другой.
Рис. 6.1. Пример ERD-диаграммы,
Определение сущностей и атрибутов
Сущность - это субъект, место, вещь, событие или понятие, содержащие информацию. Точнее, сущность - это набор (объединение) объектов, называемых экземплярами. В приведенном на рис. 6.1 примере сущность CUSTOMER (клиент) представляет всех возможных клиентов. Каждый экземпляр сущности обладает набором характеристик. Так, каждый клиент может иметь имя, адрес, телефон и т. д. В логической модели все эти характеристики называются атрибутами сущности.
На рис. 6.2 показана ERD-диаграмма, включающая в себя атрибуты сущностей.
Рис. 6.2. ERD- диаграмма с атрибутами
Логические взаимосвязи
Логические взаимосвязи представляют собой связи между сущностями. Они определяются глаголами, показывающими, как одна сущность относится к другой.
Некоторые примеры взаимосвязей:
- команда включает много игроков,
- самолет перевозит много пассажиров,
- продавец продает много продуктов.
Во всех этих случаях взаимосвязи отражают взаимодействие между двумя сущностями, называемое «один-ко-многим». Это означает, что один экземпляр первой сущности взаимодействует с несколькими экземплярами другой сущности. Взаимосвязи отображаются линиями, соединяющими две сущности с точкой на одном конце и глаголом, располагаемым над линией.
Кроме взаимосвязи «один-ко-многим» существует еще один тип - это «многие-ко-многим». Этот тип связи описывает ситуацию, при которой экземпляры сущностей могут взаимодействовать с несколькими экземплярами других сущностей. Связь «многие-ко-многим» используют на первоначальных стадиях проектирования. Этот тип взаимосвязи отображается сплошной линией с точками на обоих концах.
Связь «многие-ко-многим» может не учитывать определенные ограничения системы, поэтому может быть заменена на «один-ко-многим» при последующем пересмотре проекта.
Проверка адекватности логической модели
Если взаимосвязи между сущностями были правильно установлены, то можно составить предложения, их описывающие. Например, по модели, показанной на рис. 6.3, можно составить следующие предложения:
Самолет перевозит пассажиров. Много пассажиров перевозятся одним самолетом.
Составление таких предложений позволяет проверить соответствие полученной модели требованиям и ограничениям создаваемой системы.
Рис. 6.3. Пример логической модели со взаимосвязью
Модель данных, основанная на ключах
Каждая сущность содержит горизонтальную линию, разделяющую атрибуты на две группы. Атрибуты, расположенные над линией, называются первичным ключом. Первичный ключ предназначен для уникальной идентификации экземпляра сущности.
Выбор первичного ключа
При создании сущности необходимо выделить группу атрибутов, которые потенциально могут стать первичным ключом (потенциальные ключи), затем произвести отбор атрибутов для включения в состав первичного ключа, следуя следующим рекомендациям:
Первичный ключ должен быть подобран таким образом, чтобы по значениям атрибутов, в него включенных, можно было точно идентифицировать экземпляр сущности. Никакой из атрибутов первичного ключа не должен иметь нулевое значение. Значения атрибутов первичного ключа не должны меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.
При выборе первичного ключа можно внести в сущность дополнительный атрибут и сделать его ключом. Так, для определения первичного ключа часто используют уникальные номера, которые могут автоматически генерироваться системой при добавлении экземпляра сущности в БД. Применение уникальных номеров облегчает процесс индексации и поиска в БД.
Первичный ключ, выбранный при создании логической модели, может быть неудачным для осуществления эффективного доступа к БД и должен быть изменен при проектировании физической модели.
Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Key). ERWin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).
Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERWin генерирует неуникальный индекс для каждого инверсионного входа.
При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.
Пример
Рассмотрим процесс построения логической модели на примере БД студентов системы «Служба занятости в рамках вуза». Первым этапом является определение сущностей и атрибутов. В БД будут храниться записи о студентах, следовательно, сущностью будет студент.
Таблица 6.1. Атрибуты сущности «Студент»
| Атрибут | Описание |
| Номер | Уникальный номер для идентификации пользователя |
| Ф.И.О. | Фамилия, имя и отчество пользователя |
| Пароль | Пароль для доступа в систему |
| Возраст | Возраст студента |
| Пол | Пол студента |
| Характеристика | Memo-поле с общей характеристикой пользователя |
| Адреса электронной почты | |
| Телефон | Номера телефонов студента (домашний, рабочий) |
| Опыт работы | Специальности и опыт работы студента по каждой из них |
| Специальность | Специальность, получаемая студентом при окончании учебного заведения |
| Специализация | Направление специальности, по которому обучается студент |
| Иностранный язык | Список иностранных языков и уровень владения ими |
| Тестирование | Список тестов и отметки о их прохождении |
| Экспертная оценка | Список предметов с экспертными оценками по каждому из них |
| Оценки по экзаменам | Список сданных предметов с оценками |
В полученном списке существуют атрибуты, которые нельзя определить в виде одного поля БД. Такие атрибуты требуют дополнительных определений и должны рассматриваться как сущности, состоящие, в свою очередь, из атрибутов. К таковым относятся: опыт работы, иностранный язык, тестирование, экспертная оценка, оценки по экзаменам. Определим их атрибуты.
Таблица 6.2. Атрибуты сущности «Опыт работы»
Таблица 6.3. Атрибуты сущности «Иностранный язык»
Таблица 6.4. Атрибуты сущности «Тестирование»
Таблица 6.5. Атрибуты сущности «Экспертная оценка»
| Атрибут | Описание | |
| Дисциплина | Наименование дисциплины, по которой оценивался студент | |
| Ф.И.О. преподавателя | Ф.И.О. преподавателя, который оценивал студента | |
| Оценка | Экспертная оценку преподавателя | |
| Атрибут | Описание | |
| Предмет | Название предмета, экзамен по которому сдавался | |
| Оценка | Полученная оценка | |
Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи между сущностями (рис. 6.4). Все сущности будут зависимыми от сущности «Студент». Связи будут типа «один-ко-многим».
Рис. 6.4. ERD-диаграмма БД студентов
На полученной диаграмме рядом со связью отражается ее имя, показывающее соотношение между сущностями. При проведении связи между сущностями первичный ключ мигрирует в дочернюю сущность.
Следующим этапом при построении логической модели является определение ключевых атрибутов и типов атрибутов.
Таблица 6.7. Типы атрибутов
| Атрибут | Тип |
|
Характеристика |
|
|
Специальность |
|
|
Специализация |
|
|
Место работы |
|
|
Уровень владения |
|
|
Название |
|
|
Описание |
|
|
Дисциплина |
|
|
Ф.И.О. преподавателя |
|
Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Студент» это будет уникальный номер, для сущности «Опыт работы» все поля являются ключевыми, так как по разным специальностям студент может иметь разный опыт работы в разных фирмах. Сущность «Тест» определяется названием, так как студент по одному тесту может иметь только одну оценку. Оценка по экзамену определяется только названием предмета, экспертная оценка зависит от преподавателя, который ее составил, поэтому в качестве ключевых атрибутов выберем «Дисциплину» и «Ф.И.О. преподавателя». У сущности «Иностранный язык» уровень владения зависит только от наименования языка, следовательно, это и будет являться ключевым атрибутом.
Получим новую диаграмму, изображенную на рис. 6.5, где все ключевые атрибуты будут находиться над горизонтальной чертой внутри рамки, изображающей сущность.
Рис. 6.5. ERD-диаграмма БД студентов с ключевыми атрибутами
Контрольные вопросы
- Назовите основные части ERD-диаграммы.
- Цель ERD-диаграммы.
- Что является основным компонентом реляционных БД?
- Что называется сущностью?
- Сформулируйте принцип именования сущностей.
- Что показывает взаимосвязь между сущностями?
- Назовите типы логических взаимосвязей.
- Каким образом отображаются логические взаимосвязи?
- Опишите механизм проверки адекватности логической модели.
- Что называется первичным ключом?
- Назовите принципы, согласно которым формируется первичный ключ.
- Что называется альтернативным ключом?
- Что называется инверсионным входом?
- В каком случае образуются внешние ключи?
- Тема, цель работы.
- ERD-диаграмма БД Служба занятости с атрибутами и ключами.
- Выводы по работе
Аннотация
В данной курсовой работе описывается проектирование базы данных центральной городской больницы и ее реализация в Oracle Datebase. Была представлена предметная область, разработаны концептуальная, логическая и физическая модели данных. Средствами Oracle Datebase созданы необходимые таблицы, запросы, отчеты. Курсовая работа состоит из.
Введение 3
1.Предметная область 4
2.Концептуальная модель 5
3.Логическая модель базы данных 7
4.Модель физической организации данных 9
5.Реализация баз данных в Oracle 9
6.Создание таблиц 10
7.Создание запросов 16
8.Заключение 27
Список литературы 28
Введение
База данных – это единое, вместительное хранилище разнообразных данных и описаний их структур, которое после своего определения, осуществляемого отдельно и независимо от приложений, используется одновременно многими приложениями.
Кроме данных база данных может содержать средства, позволяющие каждому из пользователей оперировать только теми данными, которые входят в его компетенцию. В результате взаимодействия данных, содержащихся в базе, с методами, доступными конкретным пользователям, образуется информация, которую они потребляют и на основании которой в пределах собственной компетенции производят ввод и редактирование данных
Целью данной курсовой работы является разработка и реализация базы данных для центральной больницы, что бы обеспечить хранение, накопление и предоставление информации о деятельности больницы. Создаваемая база данных предназначена в основном для автоматизации деятельности основных подразделений больницы.
Предметная область
Предметной областьюназывается часть реальной системы, представляющая интерес для данного исследования. При проектировании автоматизированных информационных систем предметная область отображается моделями данных нескольких уровней. Число уровней зависти от сложности решаемых задач, но в любом случае включает концептуальный и логический уровни.
В данной курсовой работе предметной областью является работа центральной больницы, которая занимается лечением больных. Организационная структура больницы состоит из двух отделов: регистратуры и приёмного покоя. В регистратуре проводятся записи на приём, выдаются направления, распределяют пациентов по палатам, фиксируют номера страховых полюсов. Приёмный покой, в свою очередь, ведет учет поступления и выписки, диагнозы пациентов, историю болезни.
База данных предназначена для хранения данных о больных, их размещении, выписываемых препаратах и о лечащих врачах.
Концептуальная модель
Первая фаза процесса проектирования базы данных заключается в создании для анализируемой части предприятия концептуальной модели данных.
Концептуальная модель - это модель предметной области. Компонентами модели являются объекты и взаимосвязи. Концептуальная модель служит, средством общения между различными пользователями и поэтому разрабатывается без учета особенностей физического представления данных. При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на основе анализа решаемых на этом предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области. Взаимосвязи между объектами являются частью концептуальной модели и должны отображаться в базе данных. Взаимосвязь может охватывать любое число объектов. С другой стороны, каждый объект может участвовать в любом числе связей. Наряду с этим существуют взаимосвязи между атрибутами объекта. Различают взаимосвязи типа: "один к одному", "один ко многим", "многие ко многим".
Самой популярной моделью концептуального проектирования является модель «сущность-связь» (ER-модель), она относится к семантическим моделям.
Основными элементами модели являются сущности, связи между ними и их свойства (атрибуты).
Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Каждая сущность в модели изображается в виде прямоугольника с наименованием.
Атрибут – характеристика (параметр) не которой сущности.
Домен – множество значений (область определения атрибутов).
У сущностей выделяются ключевые атрибуты – ключ сущности – это один или более атрибутов, уникально определяющих данную сущность.
Набор сущностей для центральной больницы (в скобках указаны атрибуты сущностей, подчёркнуты ключевые атрибуты):
ПАЦИЕНТЫ (Код пациента , фамилия, имя, дата рождения, номер страхового полиса, код отделения);
ЛЕЧЕНИЕ (Код больного , диагноз, дата выписки, код врача, стоимость);
ОТДЕЛЕНИЯ(Код отделения , название отделения, количество палат);
ПОСТУПЛЕНИЯ (Код больного, дата поступления, код палаты);
ПАЛАТЫ (Код палаты , кол-во мест, код отделения);
ВРАЧИ (Код врача, фамилия, имя, дата рождения, номер личного дела, код отделения);
Диаграмма «сущность-связь» для районной больницы изображена на рисунке 1.
Логическая модель базы данных
Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью. Процесс построения логической модели базы данных должен опираться на определённую модель данных (реляционная, сетевая, иерархическая), которая определяется типом предполагаемой для реализации информационной системы СУБД. В нашем случае база данных создается в среде Oracle и будет представлять собой реляционную базу данных.
Реляционная модель характеризуется своей простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для манипулирования данными..
В реляционных моделях данных объекты и взаимосвязи между ними представляются с помощью таблиц. Каждая таблица представляет один объект и состоит из строк и столбцов. Таблица в реляционной модели называется отношением.
Атрибут (поле) – любой столбец в таблице.
Кортежи (записи) – строки таблицы.
Таблицы связаны между собой при помощи ключевых полей.
Ключ – это поле, позволяющее однозначно идентифицировать запись в таблице. Ключ может быть простым (состоит из одного поля) или составным (из нескольких полей).
В реляционных базах данных логическое проектирование приводит к разработке схемы данных, которая представлена на рисунке 2.
Рис.2.
4. Модель физической организации данных
Физическая модель данных описывает то, как данные хранятся в компьютере, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа.
В физической модели описываются типы, идентификаторы и разрядность полей. Физическая модель данных отражает физическое размещение данных на машинных носителях, то есть какой файл, какие объекты, с какими атрибутами содержит и каковы типы этих атрибутов.
©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-26
Логическая модель данных - описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы.
Логическая модель строится в несколько этапов с постепенным приближением к оптимальному для данных условий варианту. Эффективность такой модели зависит от того, насколько близко она отображает изучаемую предметную область. К предметной области относятся объекты (документы, счета, операции над ними и пр.), а также характеристики данных объектов, их свойства, взаимодействие и взаимное влияние.
Таким образом, при построении логической модели данных сначала выявляются те объекты, которые интересуют пользователей проектируемой базы данных. Затем для каждого объекта формулируются характеристики и свойства, достаточно полно описывающие данный объект. Эти характеристики в дальнейшем будут отражены в базе данных как соответствующие поля.
Логическая модель данных строится в рамках одного из трех подходов к созданию баз данных. Выделяют следующие виды логических моделей базы данных:
Иерархическая;
Сетевая;
Реляционная.
Иерархическая модель представляет собой древовидную структуру, которая выражает связи подчинения нижнего уровня высшему. Это облегчает поиск информации в том случае, если запросы имеют такую же структуру.
Сетевая модель отличается от предыдущей наличием также и горизонтальных связей. Это усложняет как модель, так и саму базу данных и средства ее управления.
Реляционная модель представляет хранимую информацию в виде таблиц, над которыми возможно выполнение логических операций (операций реляционной алгебры). В настоящий момент этот вид моделей получил наибольшее распространение. Это связано со сравнительной простотой реализации, четкой определенностью отношений между объектами, простотой изменения структуры базы данных.
Описание пользователей и групп пользователей системы
Разрабатываемая информационно-справочная система может быть использована как сотрудниками кинотеатра, так и посетителями. Сотрудник кинотеатра может обеспечивать редактирование имеющейся информации об имеющихся фильмах, изменять график работы кинотеатра, включать вновь поступившие фильмы в репертуар кинотеатра; а посетитель может просматривать информацию о графике работы кинотеатра, стоимости билетов, фильмах на сегодня.
Модель предметной области
Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model). Модель "сущность-связь" основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Категории «сущность» и «связь» объявляются основополагающими, и разделение их производится на этапе создания конкретных представлений некоторой предметной области.
Каждая сущность принадлежит к некоторому классу, иначе говоря, ей соответствует некоторый тип. Между сущностями имеются связи, которые пользователь относит к определенному классу (типу). Таким образом, класс сущностей и класс связей определяют множества конкретных объектов и связей между ними. Некоторая сущность может принадлежать более чем к одному классу.
Совокупность сущностей и классов связей образует верхний уровень модели.
Сущности и связи описываются характерными для них атрибутами. Среди атрибутов какой-нибудь сущности или связи выделяется подсписок, значения атрибутов которого однозначно идентифицируют сущность или связь в пределах типа. Сущности, связи и атрибуты образуют нижний уровень модели.
Важным является тот факт, что из модели "сущность-связь" могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.
Модель «сущность-связь» представлена в Приложении Е.
Реляционная база данных состоит из нормализованных таблиц. В процессе загрузки и корректировки базы данных, для получения информации по запросам и вывода отчётов, а также для решения большинства задач необходим одновременный доступ к нескольким взаимосвязанным таблицам. Взаимосвязь между таблицами базы данных устанавливается реляционными соотношениями.
Связи, определенные в схеме данных, используются автоматически при разработке многотабличных форм, запросов, отчетов, существенно упрощая процесс их конструирования.
Программный продукт представлен проектом - Cinema, который имеет 4 связанных между собой таблицы:
Bilety - информация реализованных билетах;
Films - информация о всех имеющихся в кинотеатре фильмах;
Seansy - информация о времени проведения сеансов и стоимости билетов на эти сеансы;
Today - информация о фильмах, которые будут показаны на сегодняшний день.
