Разработка серверной части базы данных с применением CASE-технологий (стр. 1 из 2)

Содержание

Задание

Введение

1. Создание логической модели

2. Создание физической модели

3. Схема данных в SQL

Заключение

Список используемой литературы

Приложение

Задание

Предметная область "Учебная точка""Аудитория"

Введение

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

Обычно разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической модели. ERwin полностью поддерживает такой процесс, он имеет два представления модели: логическое (logical) и физическое (physical). Таким образом, разработчик может строить логическую модель базы данных, не задумываясь над деталями физической реализации, т.е. уделяя основное внимание требованиям к информации и бизнес-процессам, которые будет поддерживать будущая база данных. ERwin не только имеет очень удобный пользовательский интерфейс, позволяющий представить базу данных в самых различных аспектах, но и поддерживает автоматическую генерацию спроектированной и определенной на физическом уровне структуры данных. При создании новой модели выбирается сервер СУБД. Выбранный сервер определяет физический уровень представления модели. Для того, чтобы переключится на физический уровень модели, нужно выбрать кнопку Phisical/Logical на панели инструментов.

1. Создание логической модели

Логическая модель данных является визуальным представлением структур данных, их атрибутов и бизнес-правил. На нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Логическая модель представляет данные таким образом, чтобы они легко воспринимались. С точки зрения пользователя Erwin, процесс создания логической модели данных заключается в визуальном редактировании ER-диаграммы. Диаграмма Erwin строится из трех основных блоков: сущностей, атрибутов и связей.Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Проектирование логической модели свободно от требований платформы и языка реализации или способа дальнейшего использования данных. Разработчик модели использует требования к данным и результаты анализа для формирования логической модели данных. Разработчик приводит логическую модель к третьей нормальной.

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

Первичные ключи предметной области "Учебная точка":

-сущность "Аудитория"- № аудитории;

-сущность "Учебная группа"- № группы;

-в сущности "Расписание" составной первичный ключ - № аудитории и № группы.

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

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

В предмотной области "Учебная точка" имеются внешние ключи (№ аудитории и № группы) в сущности "Расписание".

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

- Первая нормальная форма

Говорят, что сущность соответствует первой нормальной форме, если в каждом поле каждой ее строки содержится ровно одно значение.

- Вторая нормальная форма

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

- Третья нормальная форма

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

Все сущности предметной области "Учебная точка" отвечают требованиям 3 нормальных форм.

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

Логическая модель предметной области "Учебная точка":

2. Создание физической модели

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога БД. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, столбцах и отношениях. Сущности логической модели, вероятно, станут таблицами в физической модели. Логические атрибуты станут столбцами. Логические отношения станут ограничениями целостности связей. Некоторые логические отношения невозможно реализовать в физической базе данных.

На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Для выполнения прямого проектирования служит меню Tool/ ForwardEngineering/SchemaGeneration. Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой.

ERwin поддерживает большинство ведущих наиболее популярных реляционных СУБД, а также настольные системы: Access, Microsoft SQL Server, Oracle, FoxPro, dBase, Clipper , Paradox и многие другие. При смене СУБД ERwin автоматически преобразует одну физическую модель в другую. В окне TargetServer можно выбрать новый сервер СУБД. Сервер СУБД можно изменить при помощи пункта меню Database/ChooseDatabase.

Физическая модель предметной области "Учебная точка":

3. Схема данных в SQL

Заключение

Под термином CASE (Computer Aided Software Engineering) понимаются программные средства, поддерживающие процессы создания и сопровождения АС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным программным обеспечением и техническими средствами образуют полную среду разработки АС.

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

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

Однако во многих случаях проектирование АС выполняется в основном на интуитивном уровне с применением неформальных методов, основанных на искусстве, практическом опыте и экспертных оценках.

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