Автор: Пользователь скрыл имя, 22 Декабря 2011 в 18:29, реферат
Построение логической модели данных
Результатом моделирования должна стать полная атрибутивная модель - наиболее глубокое представление информации о данных и их взаимосвязи. Построение логической модели сводится к следующим этапам.
1. Идентификация всех сущностей, их атрибутов и первичных ключей.
2. Идентификация всех связей между сущностями и указание их мощности.
3. Преобразование выявленных отношений N:N в отношения 1:N с помощью добавления новых (ассоциированных) сущностей.
Построение логической модели данных………………………………………3
Генерация физической модели данных…………………………………….8
Генерация базы данных………………………………………………….…..10
Федеральное государственное бюджетное образовательное учреждение
«Омский
государственный технический
Кафедра
«Математические методы и информационные
технологии в экономике»
Расчетно
– графическая
работа
по теме «Разработка баз данных с использованием
CASE-технологий»
Выполнил
Студент гр. ПИ-329
_________Г.Е.
Филиппова
Принял
____________О. Б. Малков
«____»___________2011
г.
Омск 2011 г
Содержание
Построение логической модели данных………………………………………3
Генерация физической модели данных…………………………………….8
Генерация базы
данных………………………………………………….…..
Построение логической модели данных
Результатом моделирования должна стать полная атрибутивная модель - наиболее глубокое представление информации о данных и их взаимосвязи. Построение логической модели сводится к следующим этапам.
1. Идентификация всех сущностей, их атрибутов и первичных ключей.
2. Идентификация всех связей между сущностями и указание их мощности.
3. Преобразование выявленных отношений N:N в отношения 1:N с помощью добавления новых (ассоциированных) сущностей.
Выделение сущностей предметной области, отвечающих требованиям нормализации, может производиться на основе различных подходов.
Интуитивный подход предполагает непосредственное выявление реальных объектов и других сущностей предметной области и определение их характеристик. При таком подходе возможны существенные ошибки, если отсутствует достаточный опыт. Последующая проверка выполнения требований нормализации обычно показывает необходимость уточнения атрибутного состава сущностей. Получаемая при этом модель, как правило, требует дальнейших преобразований - преобразования транзитивных зависимостей реквизитов и много-многозначных связей.
При наличии сложившегося документооборота можно применить другой подход, основанный на анализе функциональных зависимостей реквизитов документов предметной области. Реквизиты подразделяются на ключевые и описательные, которые являются функционально зависимыми от ключа Функциональная зависимость реквизитов имеет место только в том случае, если одному значению ключа соответствует только одно значение зависимого (описательного) реквизита.
Функциональную зависимость реквизитов можно изобразить графически в виде линий со стрелками, идущими от ключевого реквизита к описательному (зависимому). Ключевой реквизит выделяется (подчеркивается). Эти связи удобно отображать в таблице, где представлен состав реквизитов каждого документа (табл. 1).
Документ |
Название реквизита |
Функциональная зависимость |
группа | № группы
Число студентов Староста Факультет Курс Специальность |
|
При выявлении функциональных зависимостей реквизитов не рассматриваются арифметические зависимости (например, стоимость от количества). Алгоритм выявления сущностей включает следующие действия.
Представить список реквизитов каждого документа предметной области в виде таблицы.
Установить функциональные зависимости между реквизитами на основе описания предметной области и анализа форм документов. При наличии функциональной зависимости проводится линия связи со стрелкой от ключевого реквизита к зависимому.
Разделить
все реквизиты на описательные (зависимые)
и ключевые. В случае транзитивной
зависимости некоторые
Сгруппировать описательные реквизиты, одинаково зависимые от одного (или нескольких) реквизитов. В каждую группу включить общие для группы ключевые реквизиты. Каждая такая группа из описательных реквизитов (атрибутов) с общим для них ключом образует одну выделяемую сущность.
Эти правила позволяют на основе несложного анализа функциональных зависимостей реквизитов (атрибутов) группировать их в отдельные сущности, отвечающие требованиям нормализации. При использовании этих правил не требуется отдельно преобразовывать транзитивные зависимости реквизитов. Сразу оказываются выделенными ассоциированные сущности, выполняющие роль связки между сущностями, находящимися в отношении N:N. Ассоциированная сущность становится зависимой в одно-многозначных связях по отношению к каждой из исходных.
При выявлении функциональных зависимостей реквизитов не рассматриваются арифметические зависимости (например, стоимость от количества). Алгоритм выявления сущностей включает следующие действия.
Представить список реквизитов каждого документа предметной области в виде таблицы.
Установить функциональные зависимости между реквизитами на основе описания предметной области и анализа форм документов. При наличии функциональной зависимости проводится линия связи со стрелкой от ключевого реквизита к зависимому.
Разделить
все реквизиты на описательные (зависимые)
и ключевые. В случае транзитивной
зависимости некоторые
Сгруппировать описательные реквизиты, одинаково зависимые от одного (или нескольких) реквизитов. В каждую группу включить общие для группы ключевые реквизиты. Каждая такая группа из описательных реквизитов (атрибутов) с общим для них ключом образует одну выделяемую сущность.
Эти
правила позволяют на основе несложного
анализа функциональных зависимостей
реквизитов (атрибутов) группировать их
в отдельные сущности, отвечающие требованиям
нормализации. При использовании этих
правил не требуется отдельно преобразовывать
транзитивные зависимости реквизитов.
Сразу оказываются выделенными ассоциированные
сущности, выполняющие роль связки между
сущностями, находящимися в отношении
N:N. Ассоциированная сущность становится
зависимой в одно-многозначных связях
по отношению к каждой из исходных.
Описание сущностей, сохраняющих информацию, с полным перечнем атрибутов и указанием первичных ключей приведено в табл. 4. Тип данных каждого атрибута потребуется далее, на этапе физического моделирования.
Таблица 4
Сущности ГРУППА, ДИСЦИПЛИНА являются независимыми, поскольку каждый их экземпляр однозначно идентифицируется своим кодом (номером) без определения его отношений с другими сущностями. Сущность ИЗУЧАЮТ является зависимой, поскольку данные однозначно определяются кодом дисциплины и номером группы.
Сущность ГРУППА является независимой, поскольку каждая группа однозначно идентифицируется номером. Каждый из них имеет единственное значение, так как номер группы привязан к конкретной.
Сущность ИЗУЧАЮТ является зависимой содержит множество значений в соответствующих столбцах. Идентификатором каждой строки здесь является код дисциплины и номер группы. Таким образом, данные, содержащиеся в каждой строке, однозначно определяются общим идентификатором документа — номером группы и кодом дисциплины. Описательные реквизиты изделия (в том числе единица измерения) однозначно определяются его кодом.
Определим
связи между сущностями предметной
области. Связи ГРУППА И ИЗУЧАЮТ и ДИСЦИПЛИНА
И ИЗУЧАЮТ являются неидентифицирующими
мощностью один-ко-многим. Одна группа
может изучать много дисциплин, и одна
дисциплина может изучаться несколькими
группами. Сущность ИЗУЧАЮТ раскрывает
какая группа изучает какую дисциплину.
Логическая модель представлена на рисунке 1.
Рис. 1 Логическая
модель
Генерация физической модели данных
Генерация физической модели данных осуществляется CASE-средствами автоматически. В некоторых средствах используется Мастер, проводящий пользователя через все этапы, наиболее важным из которых является адаптация к системе имен, к правилам синтаксиса целевой СУБД и выбор способов разрешения связей многие-ко-многим.
Рис. 2 Интерфейс СASE-средства ER/Studio
В CASE-средстве ER/Studio генерация физической модели осуществляется по команде Generate Physical Model за восемь шагов.
Определяется имя физической модели, из списка выбирается целевая платформа будущей БД, принимается решение о проверке правильности модели.
Выбираются объекты (таблицы), включаемые в физическую модель. Определяется способ обработки внешних ключей от не вошедших в модель таблиц.
Принимается
решение о включении или
Определяется,
какие индексы будут
Определяется, как будут обрабатываться пробелы и символы верхнего и нижнего регистра в названиях.
Выбирается логика проверки законченности и целостности таблиц (таблицы без столбцов, таблицы без первичных ключей, таблицы с типом данных по умолчанию, превышение разрешенного количества столбцов).
Выбирается логика проверки соглашения об именах (длина имен, проверка ключевых слов, которые не должны использоваться как названия и т. д.).
Выбирается способ проверки целостности индексов таблицы (проверка таблиц без индексов, проверка таблиц с индексами, превышающими пределы).
Для нашего примера в качестве целевой платформы будущей БД выберем Microsoft Access 2000. Настройки, предлагаемые Мастером по умолчанию (индексы, правила проверки и т. д.), можно оставить без изменения. По окончании генерации физической модели формируется отчет с информацией об ошибках, обнаруженных в процессе создания модели.
Можно
отредактировать вручную
Генерация базы данных
Следующим шагом является генерация кода.
На панели инструментов выбираем Database – Generate Database – Generate Objects with a Database Connection. Выбираем Connect…
Далее в разворачиваемся окне выбираем m4 (Microsoft Access Driver (*.mdb)). Далее Setup, снова выбираем m4 Microsoft Access Driver (*.mdb) – Создать. Выбираем имя новой базы данных и сохраняем на определенный диск – Next – Next – Finish
Информация о работе Разработка баз данных с использованием CASE-технологий